From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4448 invoked from network); 10 Oct 1999 13:36:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Oct 1999 13:36:26 -0000 Received: (qmail 7144 invoked by alias); 10 Oct 1999 13:35:59 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8185 Received: (qmail 7137 invoked from network); 10 Oct 1999 13:35:58 -0000 Subject: Re: PATCH: 3.0.6/3.1.6: Re: All sorts of file-descriptor strangeness In-Reply-To: <991010082734.ZM31398@candle.brasslantern.com> from Bart Schaefer at "Oct 10, 1999 8:27:34 am" To: schaefer@candle.brasslantern.com (Bart Schaefer) Date: Sun, 10 Oct 1999 14:35:56 +0100 (BST) Cc: zsh-workers@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL48 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram 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