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

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

>> 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 there are two reasons: (1) you want
specifying the facility to be separate from specifying the priority and
(2) you're writing in a language, such as sh, which doesn't have direct
access to syslog().

> =E2=9D=AF echo "alert|This in an alert message"|logger -F local2

This may well be useful, though I have some thoughts on your use case
as sketched.

I am not trying to criticize, here.  I am trying to examine all the
angles, in an attempt to help ensure you get the best fit for your use
case - and, if this ends up with a change to the main tree, that it is
more generally useful, to the extent that that's easy.

> The only point of contact is the naming of the loglevels, which is
> oriented on the syslog standard.

There are actually at least three (or arguably two - the first two are
closely related) syslog standards.

(1) There is the syslog(3) API, which uses names such as LOG_ALERT and
LOG_AUTH.

(2) There is the syslog.conf language, which uses two-part names such
as kern.notice and auth.warning, with support for some further syntax
(eg ftp.*, kern.none).

(3) There is the wire protocol, which uses small integer values in
ASCII decimal (see RFC 3164).

There may be others, but these are the ones I'm aware of.

> Otherwise, the only communication is via stderr - a way that is
> available in every conceivable programming language.

But often undesirable, as it means losing the ability to report error
messages in the usual way.  For your use case, this may not be a big
deal, as the alternative is for stderr to end up mailed to wherever
cron sends mail for that job.  (I also could quibble about "every
conceivable programming language", but I think "every practical
language on NetBSD" would probably be fair.)

> The program itself can recognize at runtime whether it writes to a
> terminal or to stderr (pipe).  [...colour when to a tty...]

If you really want.  Personally, I'm having trouble thinking of an
instance I've seen of doing that - changing output based on whether
it's going to a tty - that I don't think would better be eliminated or
controlled some other way.  But your use case is for a very restricted
domain.

However, this is pushing yet more knowledge, in this case knowledge
that "going to a tty" means "going to a tty capable of colour using
these sequences, to be displayed to a user who wants colour", back into
the program.

> Another advantage is that the logger process is started only once
> when the program is started, instead of every time a log line is
> written.

This is the remark from which I infer that you are writing in a
scripting language such as sh rather than something, like C, that has
direct access to syslog(3): if you had syslog(3) or moral equivalent,
you would be starting _zero_ processes per message logged if the
generator were to log them directly.

I also offer two thoughts: 1, if starting another process is expensive
enough to care about, do you really want to be writing in a scripting
language such as sh at all? and 2, if you're logging enough for the
cost of running logger(1) for each log message to be significant,
perhaps your logs are verbose enough that syslog is not the best way to
log them?

And one final thought on the syslog change.  Perhaps the part before
the | delimiter could be facility.priority, with either or both
optionally missing and the -F argument providing defaults used when
they are missing?  Your use case may have no use for providing anything
but the priority with the message, but others may.

> In contrast, I can't think of a practical use case for the comment
> included in the original logger code (parsing the syslog log via
> stdin).

Processing log messages (presumably received from elsewhere, most
likely using the wire protocol) in a scripting language?

/~\ 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