3 ms·

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 wo

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?

joosters 7y ago
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-streams 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.
Crinus 7y ago
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 7y ago
  See the Directed Graph Shell (dgsh), which does allow multiple streams across commands. https://www.spinellis.gr/sw/dgsh/ https://www.spinellis.gr/sw/dgsh/
  - Crinus 7y ago
    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 7y ago
> 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.
enf 7y ago
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 7y ago
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).

joosters 7y ago

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-streams 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.

Crinus 7y ago

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 7y ago
See the Directed Graph Shell (dgsh), which does allow multiple streams across commands. https://www.spinellis.gr/sw/dgsh/ https://www.spinellis.gr/sw/dgsh/
- Crinus 7y ago
  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 7y ago

> 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.

enf 7y ago

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 7y ago

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).