On Tue, Apr 8, 2014 at 3:10 AM, Leslie S Satenstein wrote: > 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 > > The proposed patch doesn't affect at all sorting behavior. It is an optional parameter, that the user can use to set the environment to ASCII, which means strict byte ordering. I imagine that's what you would want with 8-bit input. I would hate to leave such input to a unicode locale, such as is the default to current OSs. Nikos > * 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 > > >