From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7747 invoked from network); 10 Oct 1999 15:55:07 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Oct 1999 15:55:07 -0000 Received: (qmail 13734 invoked by alias); 10 Oct 1999 15:54:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8188 Received: (qmail 13726 invoked from network); 10 Oct 1999 15:54:54 -0000 From: "Bart Schaefer" Message-Id: <991010155440.ZM2271@candle.brasslantern.com> Date: Sun, 10 Oct 1999 15:54:40 +0000 In-Reply-To: Comments: In reply to Zefram "Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness" (Oct 10, 2:35pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness Cc: zsh-workers@sunsite.auc.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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