Documentation about Multios is misleading, and perhaps untrue

[Tom Boyd <tvboyd23@xxxxxxxxx>]

In the section of the manual about Multios, the manual states:

If the user tries to open a file descriptor for reading more than once, the
shell opens the file descriptor as a pipe to a process that copies all the
specified inputs to its output in the order specified, similar to cat,
provided the MULTIOS option is set. Thus

sort <foo <fubar

or even

sort <f{oo,ubar}

is equivalent to ‘cat foo fubar | sort’.


This last statement seems to be untrue. The apparent behavior I see in zsh
is that for commands of the form:

commandword < file1 < file2

file1 and file2 must be successfully opened by the shell *before* the
command is even executed. if the opening of any of the listed input files
fails or blocks, then execution of the command also fails or blocks until
all openings are unblocked.

Conversely, the command:

cat file1 file2

causes the shell to immediately execute the cat command, which then
*itself* the assumes responsibility of opening the files listed as
arguments, in order. cat has different semantics than multios: cat
*immediately* begins processing the files listed as arguments from left to
right, stopping only when it reaches the first one that blocks and resuming
when it finishes open. Also if cat encounters a file that fails to open, it
merely skips it and continues down the argument list.

myprocess < file1 < namedpipe &

will block entirely until namedpipe is opened on the sender side and only
then will it start proccessing  file1.

Conversely

cat file1 namedpipe | myprocess

will immediately start processing file1, block and wait for namedpipe to
open on the sender side, and then continue processing its fed data.

What should be done about this ?
-

tom