bug#19240: cut 8.22 adds newline

[Pádraig Brady]

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.