Re: Why isn't "sed -n p" identical to "cat"?

[Eric Blake]

On 1/9/19 4:40 PM, Assaf Gordon wrote:
> Hello,
> 
> Interesting case!
> Not sure if it's a bug or an unspecified edge-case (where
> implementations can do different things).
> 
> Adding Eric Blake for his input (and POSIX pov).
> 
> On 2019-01-09 3:12 a.m., Michael Green wrote:
>> [...] it raises a question of where the newline is coming from in the
>> following command:
>>
>>   printf a | sed -n 'x;p'

That command is unspecified by POSIX; implementations can do whatever
they want.  You cannot portably expect a newline to be added or omitted;
for that matter, you cannot even expect the incomplete line without the
trailing newline to even be processed.

That's because POSIX says that sed "is a stream editor that shall read
one or more text files", but defines text file to something that is
either empty or else formed with lines made of non-NUL characters and
terminated by newline.  If your input does not end in newline, it is not
a text file, so you can't appeal to POSIX for what will happen.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html

"3.403 Text File

A file that contains characters organized into zero or more lines. The
lines do not contain NUL characters and none can exceed {LINE_MAX} bytes
in length, including the <newline> character. Although POSIX.1-2017 does
not distinguish between text files and binary files (see the ISO C
standard), many utilities only produce predictable or meaningful output
when operating on text files. The standard utilities that have such
restrictions always specify "text files" in their STDIN or INPUT FILES
sections."

Which means we can change GNU sed to do whatever we find to be most
useful, without worrying about it breaking a POSIX-compliant client, if
we think a change is warranted.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature