>> 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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
