GNU bug report logs -
#17189
Sort bug #2
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Tue, Apr 8, 2014 at 3:10 AM, Leslie S Satenstein
<lsatenstein <at> yahoo.com>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 <eblake <at> redhat.com>
> *To:* Nikos Balkanas <nbalkanas <at> gmail.com>
> *Cc:* 17189-done <at> 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
>
>
>
[Message part 2 (text/html, inline)]
This bug report was last modified 11 years and 96 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.