Re: Test failure in redirect.

[Zefram <zefram@fysh.org>]

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