7 ms·
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 f
by dn3500 2y ago
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.
- lapsed_lisper 2y agoUnix's standard error is definitely not the first invention of a sink for errors. According to Doug McIlroy, Unix got standard error in its 6th Edition, released in May 1975 (http://www.cs.dartmouth.edu/~doug/reader.pdf http://www.cs.dartmouth.edu/~doug/reader.pdf). 5th Edition was released in June, 1974, so it's reasonable to suppose Unix's standard error was developed during that 11 month interval. By that time, Multics already had a dedicated error stream, called error_output (see https://multicians.org/mtbs/mtb763.html https://multicians.org/mtbs/mtb763.html, dated October 1973). All the same, I'd be willing to believe that Unix's standard error could have been an "independent rediscovery" of one feature made highly desirable by other features (redirection and pipes). It's not clear how much communication there was among distinct OS researcher groups back then, so even if other systems had an analogue, Bell Labs people might not have been aware of it.
- dbcurtis 2y agoThe story that I recall about the origins of stderr is that without it, pipes are a mess. Keeping stdout to just the text that you want to pipe between tools and diverting all “noise” elsewhere is what makes pipes useable.
- kragen 2y agothe article is about specifically what kind of mess and what kind of usability problems inspired the change
- temporarely 2y agoI've always felt stderr should have been stdmeta. p.s. Well, actually more completely, something like this: +---------+ [meta-in] --> | | --> meta-out | p r o c | input ==> | | ==> output +---------+
- dfee 2y agoThis is interesting: MIMO channels to a process. Single stdin/stderr/stdout is effective for a single OS process, but with so much pulled up to user land (e.g. workers via green threads) maybe it makes sense to introduce multichannel i/e/o.
- jasonjayr 2y agoI bet you'd also be onboard with files having data forks and resource forks too ... ? TBH, it's a great idea, but history proved that we apparently prefer a single stream of data and solving all the problems it brings ...
- dotancohen 2y agoWe don't have a single stream - that's the point. stdout and stderr are already different streams.
- jasonjayr 2y agoRight, I was alluding to the original Mac's filesystem, with separate data + resource forks, requiring all sorts of hacks to transfer files to and from them. Due to all the trouble of working with that across other platforms, Mac eventually gave that up at a filesystem level, and sprinkled ".DS_Store" files everywhere. TCP/IP streams are bidirectional, but there is a limited way of sending "out of band" data, though it is not used as much. It would have been nice if the stdout/stderr multiple streams extended to TCP/IP networking and even HTTP messages too.
- LegionMammal978 2y ago
- cchi_co 2y ago[dead]
- dredmorbius 2y agoSimilarly, the SAS System, originally written on an IBM mainframe in 1971 (probably OS-360 / MVS), and featured an input file (the SAS program itself) and two outputs, a LIST (the desired analytic output) and LOG, which contained status, warning, and error messages. It's not quite stderr, but clearly reflects similar thinking and was probably based on extant practices at the time.