bug#19240: cut 8.22 adds newline

[Pádraig Brady]

On 01/12/14 23:06, Eric Blake wrote:
> On 12/01/2014 03:06 PM, Pádraig Brady wrote:
> 
>> BTW the argument that it's not a text file is a bit beside the point
>> as POSIX also says text files can't contain NUL chars, but we process
>> this just fine:
>>
>>   $ printf 'a\000b' | cut -c3
>>   b
> 
> The fact that GNU offers an extension where we gracefully handle NUL
> bytes is a bonus of GNU, and does not change the fact that POSIX already
> says we are in unspecified territory and can do whatever we deem most
> useful.  I suspect that in multibyte locales with non-character encoding
> errors, the behavior becomes harder to pinpoint on what makes the most
> sense - but again, that is another aspect that makes a file binary
> rather than text and therefore falls under unspecified behavior.
> 
> 
>> Also comparing other tools like uniq we have:
>>
>> solaris> printf '1' | uniq
>> solaris> (nothing output!)
>>
>> freebsd> printf '1' | uniq
>> 1freebsd>
>>
>> coreutl> printf '1' | uniq
>> 1
>> coreutl>
> 
> What about:
> printf '1\n1' | uniq

Both solaris and FreeBSD behave like GNU with that input.

> GNU treats the two lines as identical (and thus supplied a missing \n on
> the second line); but I don't have ready access to test the other two as
> I type this.
> 
>> If we were just implementing now, I'd not output the extra '\n',
>> but changing at this stage needs to be carefully considered,
>> and with all the textutils, not just cut(1).
> 
> I tend to go the opposite - producing text output, even on non-text
> input, is more likely to be useful when piping files to other utilities
> that don't handle non-text files as gracefully as the coreutils.  But I
> definitely agree that it is not something we change lightly.
> 

cheers,
Pádraig.