[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11631: closed (Re: bug#11631: Head command does not position file po
From: |
Jim Meyering |
Subject: |
bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count) |
Date: |
Thu, 07 Jun 2012 19:38:58 +0200 |
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.
- bug#11631: Head command does not position file pointer correctly for negative line count, (continued)
- Message not available
- bug#11631: Head command does not position file pointer correctly for negative line count, Jim Meyering, 2012/06/05
- bug#11631: Head command does not position file pointer correctly for negative line count, Jim Meyering, 2012/06/05
- bug#11631: Head command does not position file pointer correctly for negative line count, Pádraig Brady, 2012/06/05
- bug#11631: Head command does not position file pointer correctly for negative line count, Jim Meyering, 2012/06/05
- bug#11631: Head command does not position file pointer correctly for negative line count, Jim Meyering, 2012/06/05
Message not available
- bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Anoop Sharma, 2012/06/06
- bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Jim Meyering, 2012/06/06
- bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Eric Blake, 2012/06/06
- bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Jim Meyering, 2012/06/06
- bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Anoop Sharma, 2012/06/07
- bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count),
Jim Meyering <=
- bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Anoop Sharma, 2012/06/08
bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Eric Blake, 2012/06/07
bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Anoop Sharma, 2012/06/08
bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count), Jim Meyering, 2012/06/06