bug#17189: Sort bug #2

[Nikos Balkanas]

On Tue, Apr 8, 2014 at 3:10 AM, Leslie S Satenstein
<address@hidden>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 <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
>
>
>