From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id KAA02469 for <mason@werple.mira.net.au>; Tue, 4 Jun 1996 10:25:05 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id UAA26145; Mon, 3 Jun 1996 20:15:01 -0400 (EDT)
Resent-Date: Mon, 3 Jun 1996 20:15:01 -0400 (EDT)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199606032245.AAA00255@hzoli.ppp.cs.elte.hu>
Subject: Redirection bug
To: zsh-workers@math.gatech.edu (Zsh hacking and development)
Date: Tue, 4 Jun 1996 00:45:18 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL17 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"7zREz3.0.RO6.40uin"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1257
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

There is a feature which appeared after Zefram's redirection fixes:

% (echo bug >&2) >& /dev/tty >& /dev/null ; sleep 1
bug
bug

sleep 1 is not necessary above, but without sleep 1 the prompt comes back
while the tee process is still running which makes the output less
readable (that's really an other much older bug).

The problem above is the duplicated `bug'.  Considering that >& foo is the
> same as foo 2>&1, this produce the same output:

% (echo bug >&2) > /dev/tty 2>&1 > /dev/null 2>&1 ; sleep 1
bug
bug

Or swapping stderr and stdout:

% echo bug 2> /dev/tty >&2 > /dev/null >&2 ; sleep 1
bug
bug

And if we omit > /dev/null:

% echo bug 2> /dev/tty >&2 >&2 ; sleep 1
bug
bug

At this point this behavour seems to be correct.  bug is duplicated since
stdout is redirected twice.  Here bug was printed only once before
zsh-2.6-beta18.  That was probably a bug.  But now it is quite
counter-intuitive that >& /dev/tty >& /dev/null duplicates stderr on
/dev/tty.  I do not understand redirection staff in exec.c very much but I
do hope that Zefram knows some elegant solution to this problem.

Zoltan