From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4790 invoked from network); 5 Feb 2002 02:46:31 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 5 Feb 2002 02:46:31 -0000 Received: (qmail 22966 invoked by alias); 5 Feb 2002 02:46:24 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16560 Received: (qmail 22954 invoked from network); 5 Feb 2002 02:46:23 -0000 Date: Tue, 5 Feb 2002 02:46:22 +0000 To: Bart Schaefer Cc: Zefram , Felix Rosencrantz , zsh-workers@sunsite.dk Subject: Re: Test failure in redirect. Message-ID: <20020205024622.GA24127@fysh.org> References: <20020131064103.12082.qmail@web10405.mail.yahoo.com> <1020204184533.ZM24919@candle.brasslantern.com> <20020204210337.GA4456@fysh.org> <1020205023130.ZM28214@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020205023130.ZM28214@candle.brasslantern.com> User-Agent: Mutt/1.3.25i From: Zefram Bart Schaefer wrote: >The "print" command has to execute, e.g. in case it's given -P and there >are side-effects of the prompt expansion due to the PROMPT_SUBST option, >but it must not produce any output and it definitely shouldn't return >nonzero. The print command's purpose is to write certain characters to stdout. In this case, it is unable to perform that operation, because stdout isn't connected to anything. Why should the treatment of that case differ from the case where it is unable to perform the intended operation due to stdout being on a full filesystem? It seems to me that an error message warning of the failure is appropriate in either case. Is there any precedent for echo/print being silent about a closed stdout but complaining about other error conditions? 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? Is there a significant amount of code that uses >&- instead of >/dev/null? I argue that such code is broken. >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 zefram@bowl:~> echo foo >/dev/null; echo $? 0 zefram@bowl:~> echo $BASH_VERSION 2.05a.0(1)-release How does your version handle >/dev/full? I get identical results from pdksh, by the way (i.e., >&- and >/dev/full both treated as errors, $?=1 but no error message). -zefram