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

[Алексей Шилин]

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

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