Unix: Why Not Stdlog? | Hacker News Reader

Unix: Why Not Stdlog?

7 pointsAtlasBarfed9 comments

Setting aside recent hipster posts about logging being dead...

I continually run into the issue when making CLI apps: where does logging go?

stdout is terrible, logging would pollute information you want piped to other programs and is noise

stderr isn't great, because log messages are more status than errors, and usually breaks error detection, handling, and processing.

Most logging frameworks I've seen belch to stdout or stderr by default. Yuck.

Most alternatives (enabled by logging frameworks) is a logfile is ... ok, but then you have logfiles polluting your FS in arbitrary locations, and the logfile location and name is going to be highly unstandardized.

So why isn't there a standard notion of stdlog in UNIXland alongside stdin, stdout, and stderr?

View on HN

Sounds like you are describing syslog. Writes to /var/log/messages by default, but you can edit the syslog config to log programs to a specific file, conventionally somewhere in the /var/log folder

This is indeed annoying, but you should probably just embrace stderr as stdNonPipeOutput and call it a day.

One of my workarounds for utility scripts is to go waaaaaaaay overboard and output results and log output as JSON-per-line. The upside of this is that I can pipe the output to jq and crack out what I want. Should command line utility scripts be spraying JSON? Probably not, but it's worked into my toolchains now. I've written worse...

I don't know why, but on the tangent of long standing Unix traditions that I question are exit codes 0 being the only success

Always wished negative exit codes were errors, positive was success and zero is no action taken

Many times in various scripts, it could helpful to know it succeeded but also how in a clean, easy way

stdout is terrible, logging would pollute information you want piped to other programs

So, the focus is on regular unix programs, not daemons.

stderr isn't great, because log messages are more status than errors, and usually breaks error detection, handling, and processing

Traditionally programs use -v flag (also -vv, -vvvv, you get the idea) to control the stderr “pressure”. Stderr is diagnostics output (stdlog), all logging should go there, but only WARN+, unless a user asked for more details. Logging regular programs to syslog is unusual.

Logging daemons via syslog(3) was usual before process managers, which now redirect stdout (which would be pointed to /dev/null otherwise) to a file, syslog or a similar facility.

Who says output to stderr means an error has occurred? Or if there's a special file number for logs, why not then five special handles per log level? And that's how you get Windows and WMI.

I see your point, but really to me stderr should see.... errors.

So a logging level of TRACE/DEBUG/INFO/WARN/ERROR/FATAL, WARN/ERROR/FATAL should probably go to stderr.

"stdlog" should get all the levels of logging/verbosity.

And should every program you run put logging into /var/log? I get if you have daemons, servers, OS tasks, etc.

But what about the mass of commands and programs that are more adhoc? I don't want /var/log polluting with 10 variants of top, text editors, grep variants, find utils, etc. If there's an error or a logging trace I want to follow for those, I just want to inspect...the stream ... a nice STANDARD stream name/number.

As a real world example of stderr meaning error, the godforsaken AWS api puts tons of error codes in stderr. If you are trying to automate around that (for, say, auth expiration and re-auth), you need to parse that crap sometimes.

There kind of is a standard notion for logging on UNIX and it's /var/log/. stderr, although it suggests a stream for errors, is actually more correctly called a diagnostic stream. Depending on how you execute your program, you could implement writing to a file in /var/log/ inside your program or you could just write to stderr (diagnostic) and redirect it to a /var/log/ file.

A habit of logging is a superpower. When things go wrong, you will not need to guess what happened, you will see the whole path how you got there.

Syslog to somewhere in /var/log is the usual route.

Logs are often not used or stored on the local machine (ie. syslogd) so it makes no sense to build that in as a standard capability.

Reply on news.ycombinator.com