Subject: Re: bug#19240: cut 8.22 adds newline

From: Eric Blake <[email-masked]>
Date: Mon, 01 Dec 2014 14:18:16 -0700

[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 :)

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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org