bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16561: Bug report for 'head' (and 'wc' et. al.)


From: Pádraig Brady
Subject: bug#16561: Bug report for 'head' (and 'wc' et. al.)
Date: Mon, 27 Jan 2014 01:24:23 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

forcemerge 16561 16329
stop

On 01/26/2014 03:07 PM, LGUC wrote:
>    THE INCOMPLETE ATTACMENT! (working on sunday makes not my lucky day.
>    Sorry for the inconveniences!.
>    Please disregard the previous 2 mails)
>      __________________________________________________________________
> 
>    Caracas, Sunday 26th, 2014
>    Ref: Bug report for 'head' (and 'wc' et. al.)
>    Dear friends:
>      Please find attached the text file 'head-tst.txt'
> 
>      As you easily can see, the following command fails and do not print
>    anything, even if the file has:  6 lines,  49 words and  250 chars:
>      'head -n -0 head-tst.txt'
>      The last line on the file does NOT end with a '\n', and this seems
>    to be the base of the problem. If you add the last '\n', 'head' works
>    pretty fine.

Right that's an issue, coincidentally recently reported:
http://bugs.gnu.org/16329
We'll include the fix for that soon.

>      So this seems to be a problem with the definition of a 'text line':
>    I guess that a line that has around 68 normal chars and 13 spaces, is
>    a good candidate to be considered as a line.
>      I found the same problem in several other core utils, being the
>    most remarcable 'wc'. If you executes:
>      'wc head-tst.txt'
>      you will get:
>        5  49 250 head-tst.txt
>      what is wrong, as the file has six (6) lines instead of five (5).
>    The last one line is missing due to the fact that it does not
>    include a '\n' at the end.
>      In 1998 I fix 'wc', and I have attached 'wc-fix.c' including only
>    the most remarkable aspects, in case it could be of any help.

So wc is different and is defined by POSIX to only count '\n' chars.
So we can't change that really. We might be able to add a --visible-lines
option that would handle this and also unicode line separators etc.
But that would require more debate since it would be a new option.

thanks,
Pádraig.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]