bug#17189: Sort bug #2

[Leslie S Satenstein]

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 <address@hidden>
>To: Nikos Balkanas <address@hidden> 
>Cc: address@hidden 
>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
>
>
>