Пятница, 3 января 2014, 9:57 -07:00 от Eric Blake <[email protected]>: >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 -- Алексей Шилин
