With the patch, what does the sort do for non-ascii input.  What about a binary sort, why input field bytes range from 0 to xff where the ytes are treated as unsigned (0..255)?      Regards  Leslie Mr. Leslie Satenstein SENT FROM MY OPEN SOURCE LINUX SYSTEM. >________________________________ > From: Eric Blake >To: Nikos Balkanas >Cc: 17189-done@debbugs.gnu.org >Sent: Monday, April 7, 2014 2:43 PM >Subject: bug#17189: Sort bug #2 > > >On 04/07/2014 12:11 PM, Nikos Balkanas wrote: > >>> >>> What more are you proposing? >>> >> >> I have already written a patch. It uses the available "-a" command line >> option to >>  "force" traditional (ascii) sorting. Have updated man pages accordingly. >> >> What is the best way to upload it? > >http://git.savannah.gnu.org/cgit/coreutils.git/tree/HACKING describes >the best way to send a patch.  However, I will warn you that we are very >reluctant to burn a short option letter if there is not already existing >practice of another non-GNU implementation using the same short option >letter for the same meaning.  Furthermore, I think that: > >LC_ALL=C sort ... > >is just about as easy to type as: > >sort --ascii ... > >and that since the former is standardized by POSIX and already supported >by non-GNU sort and in wide use now, while the latter is an extension >and not likely to percolate into common use for several years, that it >is unlikely that we will take the patch (when two ways exist to do the >same thing, we prefer the standardized way over a GNU-specific >extension).  I can't outright reject your patch without seeing it, but >am just trying to warn you that the bar for new features in coreutils is >fairly high. > > >-- >Eric Blake  eblake redhat com    +1-919-301-3266 >Libvirt virtualization library http://libvirt.org > > >