bug-coreutils
[Top][All Lists]
Advanced

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

bug#19240: cut 8.22 adds newline


From: Pádraig Brady
Subject: bug#19240: cut 8.22 adds newline
Date: Mon, 01 Dec 2014 22:06:55 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 01/12/14 21:18, Eric Blake wrote:
> [re-adding the bug, with permission]
> 
> On 12/01/2014 01:10 PM, John Kendall wrote:
>> Thanks, Eric.
>>
>> My only, admittedly weak, rebuttal is that the behavior of sort might not 
>> be the best behavior to imitate.  It's understandable why POSIX defines 
>> how sort behaves, since it's intended for multi-line input.
>>
>> It seems sed, which is frequently used for single lines of input, might be 
>> a better analogy.  Gnu sed 4.2.2 and solaris sed act the same way as 
>> solaris cut (no newline added):
>>
>> $ printf "ooooooooooo" | sed 's/o/p/g'
>> ppppppppppp$
> 
> As a counter-argument, I recall hearing of other implementations of sed
> that silently omit a trailing line that lacks a newline.  And perhaps
> GNU sed should be changed to always emit a trailing newline, but that's
> something to bring up on the sed mailing list :)

I don't think so.
I agree that a newline should only be added where needed,
especially with a low level tool like sed.

sort can reorder the last item elsewhere in the output
and so needs to output the extra '\n'.

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

>> If my weak rebuttal is unconvincing, then I wonder if a note could be 
>> added to the cut man page so that the next porter can find an answer 
>> a little easier.   As an interesting counterpoint, the Solaris version of
>> sort announces loudly when it does what POSIX requires:
>>
>> $ printf "ooooooooooo" | sort
>> sort: missing NEWLINE added at end of input file STDIN
>> ooooooooooo
>> $
> 
> Ouch - that's a bug in Solaris.  POSIX does not allow for noise on
> stderr when giving a default 0 success exit status.
> 
>>
>>
>>
>> Thanks for taking the time to clarify this.  I've been using SunOS and 
>> Solaris exclusively since 1992, so I've had a stable environment and 
>> was oblivious to the unspecified behavior that my scripts depended on.  
>>
>> Cheers,
>> John
>>
> 
> I'll leave it to other contributors to weigh in on whether omitting the
> final newline on output when it was missing on input is worth the
> complexity of a change.

Our current behaviour wrt newlines is "documented" at:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=blob;f=tests/misc/cut.pl;h=04188621b#l132
though those tests were only added in v8.21

Note I see that solaris is inconsistent with -c and -f in this regard:

solaris> printf '1\n2' | cut -c1
1
2solaris>

solaris> printf '1\n2' | cut -f1
1
2
solaris>

I kid you not that FreeBSD does the opposite and outputs
the extra '\n' in the -c case but not with -f.

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>


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).

thanks,
Pádraig.





reply via email to

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