GNU bug report logs - #11631
Head command does not position file pointer correctly for negative line count

Previous Next

Full log

Message #55 received at 11631 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Anoop Sharma <sendtoanoop <at> gmail.com>
Cc: Eric Blake <eblake <at> redhat.com>, 11631 <at> debbugs.gnu.org
Subject: Re: 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.