On: The Birth of Standard Error (2013)

[throwaway_bad]

As someone who is prone to overengineering, I wonder if they also tried adding more standard streams after that (e.g., debug or verbose, different levels you would find in logging libraries today).

I think just out/err has been proven by history but that couldn't have been obvious to the original designers?

[Crinus → throwaway_bad]

It'd be useful if there was a standardized way for applications to expose additional streams that worked exactly like stdin/stdout/stderr but with custom names.

At a first glance, named pipes (both the Unix and the Windows approach) sound like that, but they are global names - i can't have an application exposing a "commands" output stream that from the shell is piped to awk which is then piped to a "monitor" input stream of another application - and then have arbitrary number of instances of those.

You can ducktape a solution using randomly created unique global names and some shell script code, but what i think would be nice is something like:

    /* app1 */
    FILE* commands = stream("commands", "w"); /* write-only stream */
    /* app2 */
    FILE* terminal = stream("terminal", "r"); /* read-only stream */

that could be used via something like (:foo would be used wherever a file descriptor could be used to specify stream foo)

    # redirect commands stream from app1 to terminal stream of app2
    app1 :commands>&:terminal app2

    # redirect commands stream from app1 to stdout
    # (stdin of the right side which is empty, hence stdout)
    app1 :commands>&0

    # pipe commands to awk's stdin then grep then app2's terminal stream
    # regular app1 stdout is not affected and written wherever stdout is
    app1 :commands| awk blah | grep bleh 1>&:terminal | app2

the shell syntax would also need to be extended a bit to allow for parallel pipelines (e.g. app1 could also export a "comments" stream that could be piped to a separate file or to a projector application).

[DSpinellis → Crinus]

See the Directed Graph Shell (dgsh), which does allow multiple streams across commands. https://www.spinellis.gr/sw/dgsh/

[Crinus → DSpinellis]

Neat but i think this would be more useful if it was a standalone utility that did the launching itself instead of replacing your existing shell.

[eadmund → throwaway_bad]

> I wonder if they also tried adding more standard streams

Common Lisp standardises a whole bunch of different streams (their names begin & end with asterisks, but I don't think that there's a way for HN to escape those):

- standard-input: probably what you think it is

- standard-output: ditto

- error-output: what a Unix user might call standard-error …

- query-io: a bidirectional stream, used for questions & answers asked of the user interactively

- debug-io: another bidirectional stream, used for debugging

- trace-output: used for print function traces & timing information

- terminal-io: a bidirectional stream representing the terminal itself

Yeah, like a lot of Common Lisp it's overengineered, but there are some intriguing possibilities in there, too.

[joosters → throwaway_bad]

Not quite the same thing, but Windows has the concept of multiple named streams in the same NTFS file - https://docs.microsoft.com/en-us/windows/win32/fileio/file-s...

So you could write a log file with separate streams for different verbosity levels.

[enf → throwaway_bad]

Later versions of Research Unix I believe reserved another standard file descriptor for /dev/tty so it wouldn't have to have magic knowledge.

[yellowapple → throwaway_bad]

I've daydreamed about something like this for non-textual I/O (e.g. audio/video streams), so that each audio channel or display window or what have you would be a pair of file descriptors (for input and output).