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

Previous Next

Full log

View this message in rfc822 format

From: Eric Blake <eblake <at> redhat.com>
To: Anoop Sharma <sendtoanoop <at> gmail.com>
Cc: Jim Meyering <jim <at> meyering.net>, 11631 <at> debbugs.gnu.org
Subject: bug#11631: closed (Re: bug#11631: Head command does not position file pointer correctly for negative line count)
Date: Thu, 07 Jun 2012 11:45:27 -0600

[Message part 1 (text/plain, inline)]

[please don't top-post on technical lists]

On 06/07/2012 08:37 AM, 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.

But that's not generically possible to know.

> 
> 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?

Bogus question.  That's a bug in your shell scripting - if you are
worried about partial processing errors, then you must check all
intermediate steps:

ulimit -f 1; trap '' SIGXFSZ
(stdbuf -o0 head -n -1025 >someOutFile && cat) <someIpFile

That is, you should have used && rather than ;, so that cat prints
nothing on error.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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