GNU bug report logs -
#17189
Sort bug #2
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17189 in the body.
You can then email your comments to 17189 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Sat, 05 Apr 2014 04:39:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nikos Balkanas <nbalkanas <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Sat, 05 Apr 2014 04:39:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
What about this output?
sort -k1 input > out
009 2919
009 3107
0.0 9312
00a 3294
00A 3389
00a 3484
00A 3578
00a 3670
00A 4142
00b 4236
00B 4332
00b 4801
This is no sorting. It is random garbage. Since when 00a < 00B? This
utility used to work fine in earlier distributions, until you broke it down.
Please return to previous lexicographic mode and cut the "cute" things.
Nikos
[Message part 2 (text/html, inline)]
Added tag(s) notabug.
Request was from
Eric Blake <eblake <at> redhat.com>
to
control <at> debbugs.gnu.org.
(Sat, 05 Apr 2014 12:24:02 GMT)
Full text and
rfc822 format available.
Forcibly Merged 17188 17189.
Request was from
Eric Blake <eblake <at> redhat.com>
to
control <at> debbugs.gnu.org.
(Sat, 05 Apr 2014 12:24:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Sat, 05 Apr 2014 12:24:03 GMT)
Full text and
rfc822 format available.
Message #12 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
tag 17189 notabug
forcemerge 17188 17189
thanks
On 04/04/2014 10:38 PM, Nikos Balkanas wrote:
> What about this output?
What about it?
>
> sort -k1 input > out
>
> 009 2919
> 009 3107
> 0.0 9312
> 00a 3294
> 00A 3389
> 00a 3484
> 00A 3578
> 00a 3670
> 00A 4142
> 00b 4236
> 00B 4332
> 00b 4801
>
> This is no sorting. It is random garbage. Since when 00a < 00B? This
Ever since the en_US.UTF-8 locale defined strcoll() to sort in
case-insensitive dictionary order by default.
> utility used to work fine in earlier distributions, until you broke it down.
No, earlier distributions merely defaulted to LC_ALL=C instead of
LC_ALL=en_US.UTF-8. This complaint is the same as your previous one,
and the solution is the same - if you want sorting by bytes, then ensure
that your locale is set to C rather than en_US.UTF-8.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Sat, 05 Apr 2014 19:20:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 5, 2014 at 3:23 PM, Eric Blake <eblake <at> redhat.com> wrote:
> tag 17189 notabug
> forcemerge 17188 17189
> thanks
>
> On 04/04/2014 10:38 PM, Nikos Balkanas wrote:
> > What about this output?
>
> What about it?
>
> >
> > sort -k1 input > out
> >
> > 009 2919
> > 009 3107
> > 0.0 9312
> > 00a 3294
> > 00A 3389
> > 00a 3484
> > 00A 3578
> > 00a 3670
> > 00A 4142
> > 00b 4236
> > 00B 4332
> > 00b 4801
> >
> > This is no sorting. It is random garbage. Since when 00a < 00B? This
>
> Ever since the en_US.UTF-8 locale defined strcoll() to sort in
> case-insensitive dictionary order by default.
>
> > utility used to work fine in earlier distributions, until you broke it
> down.
>
> No, earlier distributions merely defaulted to LC_ALL=C instead of
> LC_ALL=en_US.UTF-8. This complaint is the same as your previous one,
> and the solution is the same - if you want sorting by bytes, then ensure
> that your locale is set to C rather than en_US.UTF-8.
>
> Thank you all. As I explained in my previous mail, an update of the man
pages is essential. A change in the UI would also be desirable,
if the standards allow it. Sorry, about my attitude, but I was getting
pretty desperate. Thanks for not flaming.
To make it up I will look into updating the man pages ;-)
A suggestion. I think that sort should sort text based on the LOCALE of
the file, not the system. Couldn't it detect automatically from the text,
whether it is is dealing with UTF-8 or iso?
If dealing with Iso, it should employ the C Locale
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Sat, 05 Apr 2014 20:38:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 17189 <at> debbugs.gnu.org (full text, mbox):
Nikos Balkanas wrote:
> Thank you all. As I explained in my previous mail, an update of the man
> pages is essential. A change in the UI would also be desirable,
> if the standards allow it. Sorry, about my attitude, but I was getting
> pretty desperate. Thanks for not flaming.
>
> To make it up I will look into updating the man pages ;-)
Hopefully you will then see the WARNING section in the man page.
*** WARNING *** The locale specified by the environment affects
sort order. Set LC_ALL=C to get the traditional sort order that
uses native byte values.
The sort documentation says this:
Unless otherwise specified, all comparisons use the character
collating sequence specified by the `LC_COLLATE' locale.(1)
...
(1) If you use a non-POSIX locale (e.g., by setting `LC_ALL' to
`en_US'), then `sort' may produce output that is sorted differently
than you're accustomed to. In that case, set the `LC_ALL' environment
variable to `C'. Note that setting only `LC_COLLATE' has two problems.
First, it is ineffective if `LC_ALL' is also set. Second, it has
undefined behavior if `LC_CTYPE' (or `LANG', if `LC_CTYPE' is unset) is
set to an incompatible value. For example, you get undefined behavior
if `LC_CTYPE' is `ja_JP.PCK' but `LC_COLLATE' is `en_US.UTF-8'.
> A suggestion. I think that sort should sort text based on the LOCALE
> of the file, not the system. Couldn't it detect automatically from
> the text, whether it is is dealing with UTF-8 or iso? If dealing
> with Iso, it should employ the C Locale
US-ASCII is a subset of UTF-8. Every ASCII file is also a valid UTF-8
file. That is by design. But it also makes it impossible to make an
assumption like this.
For example one would start out with:
Lorem ipsum dolor sit amet
Now is the time.
Don't look Ethyl!
That file would sort one way. Then someone would change the
apostrophe to the unicode one.
Lorem ipsum dolor sit amet
Now is the time.
Don’t look Ethel!
If sort tried to automatically detect behavior based upon the file
content then now the file will sort with dictionary sort ordering? I
think this would cause a large number of complaints. It would be data
dependent behavior and would break a lot of things. Plus this would
require sort to add another pass to read the file first to determine
this before applying sorting it. Please no.
Besides... One person's file of human language is another person's
file of raw bytes. Can't make assumptions like this.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Sat, 05 Apr 2014 21:10:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 17189 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 5, 2014 at 11:37 PM, Bob Proulx <bob <at> proulx.com> wrote:
> Nikos Balkanas wrote:
> > Thank you all. As I explained in my previous mail, an update of the man
> > pages is essential. A change in the UI would also be desirable,
> > if the standards allow it. Sorry, about my attitude, but I was getting
> > pretty desperate. Thanks for not flaming.
> >
> > To make it up I will look into updating the man pages ;-)
>
> Hopefully you will then see the WARNING section in the man page.
>
> *** WARNING *** The locale specified by the environment affects
> sort order. Set LC_ALL=C to get the traditional sort order that
> uses native byte values.
>
Or maybe move it to the top. Where it is, after a nearly incomprehensible
KEYDEF section,
one assumes it has smt to do with KEYDEF :-(
Some examples for KEYDEF would also be nice, since the sites I searched for
sort use,
all gave the wrong -k1.
[...snip...]
US-ASCII is a subset of UTF-8. Every ASCII file is also a valid UTF-8
> file. That is by design. But it also makes it impossible to make an
> assumption like this.
>
> For example one would start out with:
>
> Lorem ipsum dolor sit amet
> Now is the time.
> Don't look Ethyl!
>
> That file would sort one way. Then someone would change the
> apostrophe to the unicode one.
>
> Lorem ipsum dolor sit amet
> Now is the time.
> Don't look Ethel!
>
> If sort tried to automatically detect behavior based upon the file
> content then now the file will sort with dictionary sort ordering? I
> think this would cause a large number of complaints. It would be data
> dependent behavior and would break a lot of things. Plus this would
> require sort to add another pass to read the file first to determine
> this before applying sorting it. Please no.
>
> Besides... One person's file of human language is another person's
> file of raw bytes. Can't make assumptions like this.
>
Not assumptions. Facts. If coming across a UTF-8 char you know.
This simple logic is inescapable:
"Sorting input should be based on the input's locale not the system's"
The rest are implementation details. Usually answer would be in the first
few lines. Worst case scenario would be to scan the whole input.
You obviously have considered it a lot in the past, and don't expect to
solve it in this thread.
Maybe i can think of smt if you tell me your sorting algorithm. Using qsort?
>
> Bob
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Mon, 07 Apr 2014 12:50:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 04/05/2014 01:19 PM, Nikos Balkanas wrote:
>>
>> No, earlier distributions merely defaulted to LC_ALL=C instead of
>> LC_ALL=en_US.UTF-8. This complaint is the same as your previous one,
>> and the solution is the same - if you want sorting by bytes, then ensure
>> that your locale is set to C rather than en_US.UTF-8.
>>
>> Thank you all. As I explained in my previous mail, an update of the man
> pages is essential. A change in the UI would also be desirable,
> if the standards allow it. Sorry, about my attitude, but I was getting
> pretty desperate. Thanks for not flaming.
>
> To make it up I will look into updating the man pages ;-)
But the man page ALREADY says this:
*** WARNING *** The locale specified by the environment
affects sort
order. Set LC_ALL=C to get the traditional sort order that uses
native
byte values.
What more are you proposing?
>
> A suggestion. I think that sort should sort text based on the LOCALE of
> the file, not the system. Couldn't it detect automatically from the text,
> whether it is is dealing with UTF-8 or iso?
Unfortunately, no, this is not possible. You're welcome to try and
write a patch to prove me wrong, but people have already had years of
experience of using environment variables as the way to tell a program
what encoding an input file uses, precisely because there is no other
obvious way of determining a file's locale.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Mon, 07 Apr 2014 18:12:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Apr 7, 2014 at 3:49 PM, Eric Blake <eblake <at> redhat.com> wrote:
> On 04/05/2014 01:19 PM, Nikos Balkanas wrote:
>
> >>
> >> No, earlier distributions merely defaulted to LC_ALL=C instead of
> >> LC_ALL=en_US.UTF-8. This complaint is the same as your previous one,
> >> and the solution is the same - if you want sorting by bytes, then ensure
> >> that your locale is set to C rather than en_US.UTF-8.
> >>
> >> Thank you all. As I explained in my previous mail, an update of the man
> > pages is essential. A change in the UI would also be desirable,
> > if the standards allow it. Sorry, about my attitude, but I was getting
> > pretty desperate. Thanks for not flaming.
> >
> > To make it up I will look into updating the man pages ;-)
>
> But the man page ALREADY says this:
>
> *** WARNING *** The locale specified by the environment
> affects sort
> order. Set LC_ALL=C to get the traditional sort order that uses
> native
> byte values.
>
> 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?
>
> >
> > A suggestion. I think that sort should sort text based on the LOCALE of
> > the file, not the system. Couldn't it detect automatically from the text,
> > whether it is is dealing with UTF-8 or iso?
>
> Unfortunately, no, this is not possible. You're welcome to try and
> write a patch to prove me wrong, but people have already had years of
> experience of using environment variables as the way to tell a program
> what encoding an input file uses, precisely because there is no other
> obvious way of determining a file's locale.
>
> It is possible. It's been sometime, since I was parsing unicode, but if I
remember correctly,
a unicode char sets bits in its data to specify continuation. This calls
for adaptive sorting based on input.
I think Bob already mentioned, that it is not acceptable to do a second
pass on the input (worst case scenario)
to determine input locale, however, adaptive sorting should not need to.
Unfortunately it is considerable
effort and I would need to know your sorting algo. Since I don't and have
much work to do this period,
I wrote the much easier ui patch I talked before.
I find it more elegant and easier than changing the environment. If it is
acceptable, let me know how to upload it.
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Mon, 07 Apr 2014 18:44:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Mon, 07 Apr 2014 19:13:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Apr 7, 2014 at 9:43 PM, Eric Blake <eblake <at> redhat.com> wrote:
> 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.
>
>
Actually:
sort -a
is much easier on the eye, and the hand. I don't like the LC_ALL=C. A lot
of typos, caps are not easy,
environment is best suited for many programs, not single ones. Sort is just
one of 1000s of tools a user has to use daily.
Consider what would happen if users had to deal with changing the
environment in each one of these tools.
And more of the same questions from the users. Ultimately you will decide
which one creates less questions and support.
I owe you a patch, if only for the manpage. It is trivial and don't care if
it gets implemented or not. Read HACKING,
but wanted to make sure i don't overwrite anything with git. If going
through with LC_ALL, then warning should be moved
to the top right after the description. The way it is buried now under
KEYDEF, noone sees it. Plus adding an
example for KEYDEF, which is nearly incomprehensible.
Let me know which patch you prefer, so that I can upload (don't want to
flood you with patches).
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Mon, 07 Apr 2014 20:44:01 GMT)
Full text and
rfc822 format available.
Message #36 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 04/07/2014 01:12 PM, Nikos Balkanas wrote:
>> 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 ...
>>
> Actually:
>
> sort -a
>
> is much easier on the eye, and the hand.
Yes, but it presupposes burning a short option. You'll have more
success getting a long option admitted, and only after it has proven
useful would a later release then commit to a short option, unless you
can first prove that someone else (such as BSD sort) already uses -a for
that same purpose.
> I don't like the LC_ALL=C. A lot
> of typos, caps are not easy,
> environment is best suited for many programs, not single ones.
Ah, but LC_COLLATE and friends DO suit many programs - 'sort', 'ls',
shell globs, and many other programs ALL use the SAME environment
variable for determining how their use of strcoll() will behave. It
does no good to turn a blind eye to the fact that POSIX has already
standardized that any program that sorts (and not just 'sort') should
pay attention to the user's locale settings, where locale is set by
environment variables.
>
> Let me know which patch you prefer, so that I can upload (don't want to
> flood you with patches).
Whatever you're willing to send. This list is fairly low-volume
compared to other lists, such as the kernel, so we don't mind seeing
your patches, even if we decide not to apply it in entirety.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Tue, 08 Apr 2014 00:11:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <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)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Wed, 09 Apr 2014 03:14:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Wed, 09 Apr 2014 08:58:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[..snip..]
Whatever you're willing to send. This list is fairly low-volume
> compared to other lists, such as the kernel, so we don't mind seeing
> your patches, even if we decide not to apply it in entirety.
>
>
Hi Eric,
Here are both the patches, ascii-sort.diff and man-sort.diff. Sorry,
couldn't get git to produce the correct output, according
to the "HACKING" instructions (it listed 3 differenet files from the
commit, but no sort.c among them) so I am sending them
the traditional way. I am no git guru, and can't loose more time over git.
The ascii patch introduces the -a, --ascii option
and modifies the man page, while the man patch moves the warning to the
top, under the Description and adds a couple of
examples of using sort.
That's the best I can do. Do as you wish with them.
BR,
Nikos
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
[Message part 2 (text/html, inline)]
[sort_patch.tgz (application/x-gzip, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#17189; Package
coreutils.
(Wed, 09 Apr 2014 12:55:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 17189-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 04/09/2014 02:57 AM, Nikos Balkanas wrote:
>
> Here are both the patches, ascii-sort.diff and man-sort.diff. Sorry,
> couldn't get git to produce the correct output, according
> to the "HACKING" instructions (it listed 3 differenet files from the
> commit, but no sort.c among them) so I am sending them
> the traditional way. I am no git guru, and can't loose more time over git.
I'm sorry you feel that way, but sending patches as a .tgz file instead
of directly inline means more work for the maintainer. We can help you
figure out the correct git instructions, and doing so will help you on
your contributions to future projects. Following a project's preferred
submission policies shows that you have initiative and gives your
patches more clout; failing to do so makes your patches that much harder
to read and that much less likely to be applied.
As is, your patches are COMPLETELY broken. You sent them in 'ed'
format, but we REQUIRE patches to be in unified [diff -u] format (or at
a minimum, context [diff -c] format); git defaults to unified format for
a reason. 'ed' format is useless because it lacks metadata about the
patch, and without that context, it is more likely to be misapplied or
fail to apply, particularly if the recipient starts from a different
version of the file than the sender.
$ patch < ./man-sort.diff
patch: **** Only garbage was found in the patch input.
We can't work with a patch if we can't even apply it.
Since YOU have the correct starting point, the best way is to apply your
'ed' patches with 'patch', then do 'git commit -a' to commit them to
your git repository, then 'git format-patch --stdout -1' to produce the
patch in the format that we can read. Bonus points if you use 'git
send-email -1' instead of 'git format-patch', although getting 'git
send-email' set up to work correctly takes more work on your side.
> The ascii patch introduces the -a, --ascii option
How many times do I have to repeat myself? Can you point to prior art
for '-a' meaning to enforce 'LC_ALL=C' collation in any other sort
implementation? If not, then I prefer that the initial version only
supply the long option. Furthermore, I am 90-10 against including any
new --ascii option, as LC_ALL=C is already the standardized method for
achieving the same effect.
> and modifies the man page, while the man patch moves the warning to the
> top, under the Description and adds a couple of
> examples of using sort.
Moving the blurb may indeed make sense; but I can't see where you are
proposing to move it, because your patch was broken. Would you mind
resubmitting, please?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 08 May 2014 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.