bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count)

[Anoop Sharma]

On Thu, Jun 7, 2012 at 11:08 PM, Jim Meyering <address@hidden> wrote:
> Anoop Sharma wrote:
>> The thought behind the proposed change was that lseek should reflect
>> the amount of data that head has actually been able to print.
>>
>> For example, how do we want head to behave in a situation like the
>> following where files more than a particular size are not allowed
>> (with bash shell on a machine with block size of 1024 bytes)? This
>> situation can be handled by applying this patch. I agree this example
>> is custom designed to illustrate my point but what do we gain by not
>> making the check?:
>>
>> ulimit -f 1; trap '' SIGXFSZ
>> (stdbuf -o0 head -n -1025 >someOutFile; cat) <someIpFile
>>
>> What should cat print now?
>>
>> By detecting fwrite failure, we can increment file pointer by the
>> amount that was written successfully.
>> That was what I originally wanted to accomplish. However, I looked at
>> the existing implementation of head.c and found that a stock behavior
>> on fwrite failures was to exit and afraid to rock the boat too much, I
>> proposed that.
>>
>> I agree that the checking for fwrite failure is not fool-proof. But it
>> looks better than ignoring the return value.
>
> While head is ignoring that return value,
> it is not really ignoring the failure.  That would be a bug.
>
> Rather, head is relying on the fact that the stream records the failure,
> and that our atexit-invoked close_stdout function will detect the prior
> failure (via ferror(stdout)) and diagnose it.
>
> In practice, testing for fwrite failure will make no difference,
> other than adding a small amount to the size of "head".
>
> Regarding your example, what you've done above (turning off buffering)
> is very unusual.  That doesn't seem like a case worth catering to.
> And besides, since in general we don't know how much a failing fwrite
> function has actually written, there can be no guarantee that the input
> stream position somehow reflects what was written.

Thank you. I get it now.