GNU bug report logs - #16329
`head --lines=-0' prints nothing if no newline at the EOF

Previous Next

Package: coreutils;

Reported by: Алексей Шилин <rootlexx <at> mail.ru>

Date: Fri, 3 Jan 2014 16:31:01 UTC

Severity: normal

Merged with 16559, 16560, 16561

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


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

From: Алексей Шилин <rootlexx <at> mail.ru>
To: Eric Blake <eblake <at> redhat.com>
Cc: 16329 <at> debbugs.gnu.org
Subject: Re[2]: bug#16329: `head --lines=-0' prints nothing if no newline at the EOF
Date: Sat, 04 Jan 2014 21:52:44 +0400
Пятница,  3 января 2014, 9:57 -07:00 от Eric Blake <eblake <at> redhat.com>:
>Per POSIX, 'head' is only required to operate on "text files"
>http://pubs.opengroup.org/onlinepubs/9699919799/utilities/head.html
>and a "text file" must either be empty or have a trailing newline:
>http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_397
>
>So this is not necessarily a bug.

While I generally agree, that current `head' implementation doesn't violate the standard, I still consider
it a bug, because:

 * `head -n -N filename' works the same way on files both with and without trailing newline for all N
   except N == 0. For example:

   $ printf '1\n2\n3' > test
   $ head -n -1 test
   1
   2
   $ head -n -0 test
   $ 

   In fact, `head' was written explicitly to consider that trailing newline is not always present [1].

   The only reason N == 0 case works differently is that the `n_lines' variable, being unsigned and equal
   to 0, is decremented [2], and, as a result of an integer underflow, gets a very big (UINT64_MAX)
   value, which in turn, having in mind the 'all but the last K lines' meaning, leads to empty output.

   I guess, it's highly unlikely to be the intended behavior.

 * `tail -n +0 filename' has the very same meaning according to its' manual, and it works just fine:

   $ tail -n +0 test; echo
   1
   2
   3
   $ 

To sum up, current `head' behavior is likely unintended, inconsistent and confusing. That's why I still
consider it a bug, maybe of a lesser priority.

[1] http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/head.c;h=ddaa9906b41ecc20fbb67f87fab43304c9ccb674;hb=HEAD#l639
[2] http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/head.c;h=ddaa9906b41ecc20fbb67f87fab43304c9ccb674;hb=HEAD#l641

-- 
Алексей Шилин

This bug report was last modified 11 years and 118 days ago.

Previous Next


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