GNU bug report logs - #19240
cut 8.22 adds newline

Previous Next

Full log

Message #27 received at 19240 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>, John Kendall <john <at> capps.com>, 
 19240 <at> debbugs.gnu.org
Subject: Re: bug#19240: cut 8.22 adds newline
Date: Mon, 01 Dec 2014 23:15:28 +0000

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.