From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13226 invoked from network); 5 Feb 2002 05:23:10 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 5 Feb 2002 05:23:10 -0000 Received: (qmail 13352 invoked by alias); 5 Feb 2002 05:23:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16561 Received: (qmail 13338 invoked from network); 5 Feb 2002 05:23:03 -0000 From: "Bart Schaefer" Message-Id: <1020205052255.ZM28417@candle.brasslantern.com> Date: Tue, 5 Feb 2002 05:22:55 +0000 In-Reply-To: <20020205024622.GA24127@fysh.org> Comments: In reply to Zefram "Re: Test failure in redirect." (Feb 5, 2:46am) References: <20020131064103.12082.qmail@web10405.mail.yahoo.com> <1020204184533.ZM24919@candle.brasslantern.com> <20020204210337.GA4456@fysh.org> <1020205023130.ZM28214@candle.brasslantern.com> <20020205024622.GA24127@fysh.org> X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Re: Test failure in redirect. Cc: zsh-workers@sunsite.dk MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 5, 2:46am, Zefram wrote: } } Is there any precedent for echo/print being silent about a closed stdout } but complaining about other error conditions? I'd be happy with reverting it to the old state where it was silent about all write errors. It was changed because of a Debian bug report; the precedent, if any, was embodied in A04redirect.ztst. We generally haven't created tests for behavior that was known to be wrong without in some way marking it as such. As the test code from more than a year ago was specifically testing for successful exit of print to a closed stdout, somebody (probably PWS) must at some point have believed that to be the correct behavior. } The only argument I see for not treating a closed stdout as an error } when one attempts to write to it is to allow >&- to be used to throw } away output. What's wrong with >/dev/null? There's no requirement that /dev/null exist in order for zsh to compile and run. There has in the past been a pure Windows port of zsh, even though it's sort of been superceded by the Cygwin build now. } Is there a significant amount of code that uses >&- instead of >/dev/null? I couldn't say if there's a "significant" amount, but closing stdout to supress output was not an uncommon scripting hack in the past. (I'd say the "distant" past, but that would make me feel old.) } >E.g. here's bash: } > } >[schaefer@zagzig schaefer]$ echo foo >&- } >[schaefer@zagzig schaefer]$ echo $? } >0 } >[schaefer@zagzig schaefer]$ } } I get results inconsistent with that: } } zefram@bowl:~> echo foo >&-; echo $? } 1 } zefram@bowl:~> echo foo >/dev/full; echo $? } 1 I get $? of 0 for both of those, with bash-2.0.3. So even returning an error status is a fairly recent development. } How does your version handle >/dev/full? bash-2.0.3 gives no error message and returns 0 on write to /dev/full. (I verified that `cat > /dev/full' on the same machine gives the "no space on device" error.) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net