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

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Oct 10,  2:35pm, Zefram wrote:
} Subject: Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangen
}
} Bart Schaefer wrote:
} >} 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.
} 
} 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.)

I thought about this and was on the verge of adding it to the patch that
I sent, but it's tickling my memory that zsh did restrict RHS FDs to one
digit at some time in the distance past until someone pointed out exactly
this:

} > [...] 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.

At which point it was changed to allow arbitrary numbers, in case some
other process used to start up a shell script leaves open a FD outside
the 0-9 range that the shell script is supposed to grab for I/O.  (True,
this wouldn't work with any other shell, but it lets zsh stand in for a
compiled program in cases where other shells can't.)

Unfortunately whatever discussion there was about this predates the
existing zsh-workers archives.  Are the old zsh-list archives still on
the net anywhere, or did they get permanently clobbered when gatech
took down Richard's FTP site?

Anyway, I'm inclined to leave it as it is, with one possible change:

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

If we continue to limit the FDs on the LHS to 0-9, then we can simply
report EBADF whenever one of the "private" FDs appears on the RHS.

I'd further point out that with the /proc/*/fd filesystem available, the
shell would have to go to nearly impossible lengths to prevent its private
FDs from becoming visible; the best it can do is to keep them from being
stomped on, which it already is doing.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com