Re: yesno module consumes too much input

[Jim Meyering]

Eric Blake <address@hidden> wrote:

> According to Bruno Haible on 8/18/2007 5:12 PM:
>>>
>>> results in calling close_stdin first.  From there, if close_stdin detects
>>> an error, there is the potential for stdout/stderr to be unflushed (and
>>> thus output data lost) when close_stdin calls _exit.
>>
>> I would just document that close_stdout and close_stdin are incompatible,
>> and that close_stdin_stdout should be used instead of the two together.
>
> But that brings us right back to where we are today without any patch -
> close_stdin currently calls close_stdout in the correct timing, so an
> application does either atexit(close_stdin) or atexit(close_stdout), but
> not both.
>
>> You can see that in coreutils, these functions are only used with atexit,
>> at exactly one place in main(). The maintainer can statically determine
>> whether he needs close_stdin or not, and if so, use close_stdin_stdout.
>
> So maybe we are back to square one - leave yesno() alone (ie. it should
> not install any atexit handler), and instead, document in yesno that any
> caller should consider adding atexit(close_stdin) in main.
>
> Affected programs (list might not be complete):
> cp
> find
> install
> ln
> mv
> rm
>
> Jim, you are affected the most - which would you rather see, a relatively
> big patch to yesno/closein that potentially changes API, or a one-line
> patch to each of your five affected programs?

The complexity of the yesno-modifying approach seems too high,
and not limited just to yesno, so I think the per-application
one-line changes are better.