> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B