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.
