Separate error output was around for at least a decade before this. I know MTS had it in the 1960s, and I don't think it was their original idea. I used a CDC for a while and they had it too. So while this is the story of how standard error was introduced into Unix, it is not the origin story of the concept of standard error.
> "One afternoon several of us had the same experience -- typesetting something, feeding the paper through the developer, only to find a single, beautifully typeset line: "cannot open file foobar"<p>reminds me of those t-shirts or digital billboards displaying some system error that we've all seen as memes
What I hate about stderr is that it's character-based, not line-based.<p>I often get output from multiple threads or multiple processes garbled together on the same line. I know how to fix this, but I feel my OS should do it for me.
This is not exactly the most earth-shattering revelation, but man: handling and communicating errors always seems to be a source of a vast amount of inelegance in software.<p>I'd argue we haven't really "solved" the optimal way to do error handling in programming: Using union types remains one of the best options, but even that has its downsides. Consider the ergonomics of forwarding an error type multiple layers in a Rust program: you can remove some of the boilerplate by strapping macros on top, but I'd argue that's more of a bandage than a fix. Most other programming languages are either using exceptions, which I don't like as they complicate control flow behavior significantly, or simply ignore error <i>handling</i> entirely (like C and Go; Both of them provide some standard facilities for dealing with error <i>values</i>, but handling it is completely manual. I do like this, since it's very straightforward, but it nonetheless is just sidestepping the problem.) And even trying to keep it simple can create new problems, like of course the way pthreads has to contort errno into a thread-local, for reasons obvious.<p>And while stderr has created a somewhat unified channel for dumping errors <i>into</i>, once they've bubbled up to the point where the program needs to output it, there's an almost unlimited amount of opinions on exactly how error logging should work. Some software won't use stderr by default, others only uses stderr for specific types of errors. Some software dumps <i>everything</i> that isn't data output into stderr, including e.g. `--help` text, whereas some software uses stdout for anything that isn't explicitly an error (Which often leads to me needing to pipe --help to less twice: once without, and once with 2>&1.) Categorization of error logging is also somewhat contentious: should there be a "warning" severity? should you split errors into modules? Formatting, too: what should be in a log line? Should logs be structured into a machine-readable format such as JSON?<p>It was probably a bad omen that even very old versions of UNIX ran into problems dealing with error logging and wound up needing to bifurcate things. Few programs feel as 'lazy' as UNIX; if UNIX couldn't ignore the problem, god knows the rest of the software was doomed.
Here I was thinking I might have another fun little bit of trivia for my Statistics class, like the T-test one from the other day (<a href="https://news.ycombinator.com/item?id=40485313">https://news.ycombinator.com/item?id=40485313</a>). Different standard error!
Some things I want from std streams:<p>Timestamping or sync points, so that if I pipe multiple streams (say stdout and stderr) I can keep them in sync further along when various buffers may have been involved.<p>Metadata, such as magic file types.<p>Structured data (this may link with meta data, and maybe there is even a way programs could negotiate what to send to each other).
Have there been systems which support other additional streams?<p>When using PowerShell, I find it useful that it handled progress separately, so it doesn't interfere with piping (putting aside that cmdlets are .NET-based objects anyway).
Is there something like stdprogress?
> As one might expect, Bell Labs didn't use the paper tape input<p>tangentially related.<p>The Great 202 Jailbreak - Computerphile<p><a href="https://www.youtube.com/watch?v=CVxeuwlvf8w" rel="nofollow">https://www.youtube.com/watch?v=CVxeuwlvf8w</a><p>staring the inimitable Professor Brailsford.