Feed facility/priority to logger(1) via stdin - desirable extension or bad idea?

[Matthias Petermann <mp%petermann-it.de@localhost>]

Hello all,

following a short discussion on IRC, I would like to ask a question or 
make a suggestion.

With a lot of scripts and tools written, I have gotten into the habit of 
logging all logging output to stderr, as well as any form of payload to 
stdout. To change the logging destination depending on the operating 
environment, I just have to connect stderr to the desired logging tool 
at the end of the pipeline. In my scripts and tools, on the other hand, 
I don't have to worry about the logging target at all, but can work as 
neutrally as possible. This is similarly recommended in the environment 
of 12F apps[1].

In my productive NetBSD environments, this logging tool is then usually 
logger(1), which is at the end of the pipeline and sends the output to 
syslogd.

logger(1) takes a parameter -p, which I can use to set the facility and 
the priority. This is where it starts to get a bit uncomfortable. I have 
no ability to influence the facility / priority on the other side of the 
pipeline. This means that I lose the capabilities of Syslogd, e.g. to 
use different log files depending on the priority.

It would be nice if one could, for example, optionally omit the -p 
parameter and instead specify the facility and priority via the standard 
input of logger in coded form (coded with angle brackets as in the raw 
syslog protocol) *)

In /usr.bin/logger/logger.c there is a TODO in the else path of command 
line processing (chosen when no command line parameters are provided) 
which mirrors pretty much that idea:

```
} else	/* TODO: allow syslog-protocol messages from file/stdin
		 *       but that will require parsing the line to split
		 *       it into three fields.
		 */
		while (fgets(buf, sizeof(buf), stdin) != NULL)
			syslogp(pri, msgid, sd, "%s", buf);
```

In other implementations of logger (under [2], for example, the Linux 
variant), there is a --prio-prefix parameter that explicitly enables 
this type of handling.

My question on this:

- With reference to the TODO - would that be a welcome addition? If yes, 
what should be paid particular attention to?

- Can what I have in mind already be solved (differently or more 
elegantly) with existing tools from the base system?


Kind regards
Matthias


*) You could then decide in your scripts, depending on whether stderr is 
connected to a terminal or a pipe, whether you want to output nice 
coloured terminal logging or logging optimised for syslog with a prefix


[1] https://12factor.net/logs
[2] https://man7.org/linux/man-pages/man1/logger.1.html