Subject: bug#16329: Re[2]: bug#16329: `head --lines=-0' prints nothing if no newline at the EOF

From: Алексей Шилин <[email-masked]>
Date: Sat, 04 Jan 2014 21:52:44 +0400

Пятница,  3 января 2014, 9:57 -07:00 от Eric Blake <[email-masked]>:
>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

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