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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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.

What do you do with error messages, then?

> 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.

Is there some reason you don't actually syslog() the log messages,
then, rather than sending them down a pipe?  It sounds to me as though
you are going to have to make your log generator logging-aware, but,
then, I don't see what benefit you get from piping the output to a tool
instead of just logging it directly.  (The obvious (to me) benefit is
that you can control facility and priority with the logging tool
instead of wiring it into the code, but here you're pushing it back
into the log-generation code anyway.)

> 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)

Regardless of the motivation, this strikes me as a reasonable thing.

> *) 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

Speaking as a user, please do not assume that anyone sending logs to a
terminal wants coloured output.  It's not true, and assuming it is
tends to produce annoyingly corrupted output when it's not applicable.
This is one of my bigger beefs with recent Ubuntu and Debian: more and
more tools blindly assume that (a) the user wants colour when the
output is going to a tty and (b) that it knows how to generate colour.
Each of those is false for me.  Typically, the resulting output looks
like this (where I forced colour on on the command line because I've
gone to some lengths to get rid of it by default):

$ ls --color=always /
[0m[01;34mbin[0m   [01;34metc[0m         [01;34mlib[0m         [01;34mmnt[0m   [01;34mroot[0m  [01;34mselinux[0m  [30;42mtmp[0m  [01;36mvmlinuz[0m
[01;34mboot[0m  [01;34mhome[0m        [01;34mlost+found[0m  [01;34mopt[0m   [01;34mrun[0m   [01;34msrv[0m      [01;34musr[0m
[01;34mdev[0m   [01;36minitrd.img[0m  [01;34mmedia[0m       [01;34mproc[0m  [01;34msbin[0m  [01;34msys[0m      [01;34mvar[0m
$ 

It's far worse with other tools.  Modern gdb borders on unusable.
Here's an example, cut-and-pasted from the window I just did a test in:

Breakpoint 1, [33ml_cmp[m ([36mcookie[m=0x55555555b220 <list>, [36ma[m=0x55555555b020 <lines>, [36mb[m=0x55555555b028 <lines+8>) at [32mtest.c[m:106
106	 [01;34mif[m [31m([mcookie [31m!=[m [31m&[mlist[31m)[m [01mpanic[m[31m();[m
[?2004h(gdb) l

gdb is blindly assuming I want colour, and furthermore assuming, not
only blindly but in defiance of active evidence that it's not so, that
the ISO 6429 values to X3.64's SGR sequence will generate it.  (The
"active evidence" is that $TERM is a type whose description includes
not only no indication of colour support but no X3.64 at all.)  It's
also generating other sequences, like that peculiar [?2004h, with the
same negative amount of reason to think they'll work.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B