bug-sed
[Top][All Lists]
Advanced

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

bug#26574: v4.4: POSIX violation with respect to output of a trailing ne


From: Eric Blake
Subject: bug#26574: v4.4: POSIX violation with respect to output of a trailing newline, even with --posix
Date: Thu, 20 Apr 2017 05:42:08 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

tag 26574 notabug
thanks

On 04/19/2017 08:43 PM, Michael Klement wrote:
> $ sed --version
> sed (GNU sed) 4.4
> 
> The POSIX spec. 
> <http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html> states:
> "Whenever the pattern space is written to standard output or a named file, 
> sed shall immediately follow it with a <newline>."
> 
> While GNU Sed's default behavior of preserving the trailing-newline status of 
> the input's last line is defensible and can be helpful,
> it should exhibit POSIX-compliant behavior when invoked with --posix.

POSIX also requires that input given to sed be text files:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html
"The input files shall be text files."

And per the definition of text file, ALL input lines must have a
trailing newline in the first place:
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-2008 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."

"3.206 Line
A sequence of zero or more non- <newline> characters plus a terminating
<newline> character."

Input that does NOT end in a trailing newline is NOT a text file, and
therefore is NOT a POSIX-compliant use of sed, and therefore, sed
--posix need not do anything different with it because you are already
outside the bounds of what POSIX requires.

Therefore, I don't think you have a case for changing any behavior, at
least not on the grounds of appealing to POSIX, so I'm marking this as
not a bug, but feel free to continue discussion.  If anything, the only
change I would make is have 'sed --posix' error out on non-text input,
to call attention to the user's attempt to feed non-posix-compliant data
to sed.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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