James Youngman wrote:
> On Sun, Apr 11, 2010 at 1:06 PM, Jim Meyering <j...@meyering.net> 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.
