multiple standard inputs

utzoo!decvax!ucbvax!unix-wizards utzoo!decvax!ucbvax!unix-wizards
Sun Dec 27 01:46:39 AEST 1981


>From mo at LBL-UNIX Sun Dec 27 01:33:39 1981
I have been thinking for a long time how to add the notion of multiple
standard inputs (and outputs?) to programs.  Mostly this is for the
notion of a "command and control input" for control arguments, with the
"real data" coming over another stdin.  However, it would be nice if
"diff3" or "pr" could take multiple inputs from other programs.  One
simple scheme I have sketched is as follows.  It is simply a
programming convention.  Since on most systems (v7 and later) it is
possible to have file descriptors tidied-up when you exec, I think it
would be possible to consider any open descriptor greater than 2
(std-error) to be a standard input.  This way, a program would probe
its descriptor space by either trying a read (and getting an error), or
opening /dev/null to see what the first free descriptor was, with
everything greater than 2 and less than the descriptor to /dev/null
being considered to be a standard input.  Another way, cleaner, but
requiring a kernel hack, would be to allow marking descriptors with
"colors" and a call to probe the descriptor space.  The Berkeley
proposal for non-blocking I/O uses a similar approach and might
integrate the whole notion in one mechanism.  There is already a flag
word for each file descriptor; adding  "stdin", "stdout", and "stderr"
bits wouldn't be too bad.  That way a common mechanism does it all.

One unresolved problem is the necessary shell syntax for this.  The
Bourne shell almost has everything you need, if not packaged too
elegantly (for this purpose, only!).  There has been work done other
places (the Software Tools world) with shells allowing networks of
processes and they have been fairly sucessful.  (And this was an
implementation which required pipes to be faked with temp files, after
computing a sufficient partial order!)

Any comments or thoughts on this general issue?? (Fool that I am....)

	-Mike



More information about the Comp.unix.wizards mailing list