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