Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness

[Zefram <zefram@fysh.org>]

Bart Schaefer wrote:
>                      that is, both ">& foo" and "&> foo" are shorthand
>for "> foo 2>&1",

Not the main topic of this thread, but that's not quite true.  It *used*
to be that way, until someone pointed out that this gave ">& foo" the
wrong behaviour with multios.  Now >& (and &>) are handled specially:
they redirect both stdout (or other specified fd) and stderr to the
specified file.  More precisely, ">& foo" has the behaviour of "9>
foo >&9 2>&9 9>&-", where "9" is any spare file descriptor.  You can
see the difference thus:

% { echo out; echo err >&2; } > foo >& bar

This puts "out" into foo and bar, but "err" into bar only.  Replacing ">&
bar" with "> bar 2>&1" gives you "out" and "err" in both files.

The documentation needs to be fixed (patch to follow).

>} The number on the right, on the other
>} hand, can be as many digits long as you like, and can even have whitespace
>} in front of it, and still zsh happily converts it to an integer and tries
>} to dup() it.
...
>                                so although you can grab a copy of a one
>of the internal file descriptors, the worst thing you can do with it is
>clobber one or more of stdin/out/err with it.  So no fix is needed here.

This is something I've always been dubious about.  One of the things I
planned to do in my CFT was to implement a syntax allowing redirection of
arbitrary file describtors, rather than just fds 0 to 9.  A consequential
requirement would be that the shell gets its private fds out of the way
whenever the user refers to a specific fd number, so this phenomenon
of the shell's fds becoming visible to the user would never occur.
I designed the Elate shell to do this from the very start -- it's not
hard -- but there are some nasty issues involved in retrofitting it to
a shell not designed that way.

I think it would be better to enforce a strict distinction between the
user's fds and the shell's.  Since the situation at the moment is that
fds 0 to 9 are the user's, I think fds on the RHS of a dup redirection
should be limited to this range.  (Patch to follow.)

-zefram