Re: [PATCH] Don't error out if stdin/stdout/stderr was already closed.

[Jim Meyering]

James Youngman wrote:
> On Sun, Apr 11, 2010 at 1:06 PM, Jim Meyering <address@hidden> wrote:
>> James Youngman wrote:
>>> * lib/closeout.c (close_stdout): Don't signal an error closing
>>> stdout or stderr if it was already closed.
>>> * lib/closein.c (close_stdin): Don't signal an error closing stdin
>>> if it was already closed.
>>> * lib/close-stream.c (close_stream): Make boolean variables const
>>> to document the fact that we set but do not change them.
>>
>> Hi James,
>>
>> Thanks for the patch, but why do you want to do that?
>>
>> Here are examples showing why we should keep the existing behavior.
>> Currently, cp diagnoses failure to write verbose output to a closed stdout:
>>
>>    $ cp --verbose a b >&-
>>    cp: write error: Bad file descriptor
>
> Right.   Here, potentially-useful data has been lost (at the
> instruction of the user, in this case).   The diagnostic is going to
> be useful for some programs.  Gnulib, being a library, has no way to
> know when the diagnostic will not be useful.
>
> However, while a failure to flush data should be diagnosed, I think
> that if no output data would in fact be lost, there is no problem and
> a diagnostic shouldn't be issued.   If you agree, I could submit a
> modified patch.

For output, that case is already handled.
Demonstrate by noting that "touch a >&-" prints no output when it succeeds.

> The use case I have in mind is a somewhat contrived example
>
> $  ./find/oldfind doc -mindepth 1 -ok echo {} \;  <&-
> < echo ... doc/Makefile > ? ./find/oldfind: error closing file

On the input side, rather than making a generic stream-closing function
ignore failure due to EBADF, how about making your code detect when
the file descriptor is invalid?  Testing fcntl (fd, F_GETFD) == -1 has
minimal cost.