zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Zefram <zefram@fysh.org>
Cc: zsh-workers@sunsite.dk
Subject: Re: Test failure in redirect.
Date: Tue, 5 Feb 2002 05:22:55 +0000	[thread overview]
Message-ID: <1020205052255.ZM28417@candle.brasslantern.com> (raw)
In-Reply-To: <20020205024622.GA24127@fysh.org>

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   


      reply	other threads:[~2002-02-05  5:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-31  6:41 Felix Rosencrantz
2002-02-04 18:45 ` Bart Schaefer
2002-02-04 21:03   ` Zefram
2002-02-05  2:31     ` Bart Schaefer
2002-02-05  2:46       ` Zefram
2002-02-05  5:22         ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1020205052255.ZM28417@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zefram@fysh.org \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).