bug-coreutils
[Top][All Lists]
Advanced

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

bug#18291: Unix Sort Bug Report


From: Eric Blake
Subject: bug#18291: Unix Sort Bug Report
Date: Mon, 18 Aug 2014 10:27:50 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0

tag 18291 notabug
thanks

On 08/18/2014 02:55 AM, NTENTOS STAVROS wrote:
> 
> Hello developers,
> 
> Recently, using the sort utility I run into an omission. While I cannot
> disclose the file in question, I will try to explain the issue:
> On a Windows-created file (line ending: \r\n) I tried to perform a
> sorting, which happened to sort the last entry somewhere above. The last
> line did not have a line ending of any kind, and sort created a
> Unix-like ending (\r), which afterwards creates a parsing problem with
> the file.

(Unix line ending is \n, not \r)

Per POSIX, sort(1) is only required to operate on text files with one
exception:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

"The input files shall be text files, except that the sort utility shall
add a <newline> to the end of a file ending with an incomplete last line."

and the POSIX definition of a text file is one that is either empty or
has a trailing newline to begin with:

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

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

As such, coreutils is doing what is already required by POSIX, and the
bug is more on you for providing a non-text file without a trailing
newline and expecting sane behavior.  I seriously doubt cygwin can
second-guess your intention to use only windows line endings, and that
you are better off guaranteeing that you have a text file with the
desired line ending already in place than relying on sort's requirement
to add a \n if the file was not a text file merely because it had an
incomplete last line.

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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