> I can't believe it, but the sort command appears to have a sorting bug!
Don't believe it! :-)
> I'm running version 2.0.14 on RedHat 7.3.
Your vendor set LANG for you to en_US because they think you like it
that way. If you disagree then you should file a bug report with
them.
Run the 'loc
On Fri, Jul 05, 2002 at 05:53:01PM -0600, Bob Proulx wrote:
> Thanks for the report. If you had not mentioned Debian I would have
> immediately jumped to the conclusion presented in this FAQ. But
> Debian does not set LANG by default without the user being informed of
> it and you would be the f
> $ cat /etc/issue
> Debian GNU 3.0 (Woody)
Thanks for the report. If you had not mentioned Debian I would have
immediately jumped to the conclusion presented in this FAQ. But
Debian does not set LANG by default without the user being informed of
it and you would be the first to have reported t
You wrote:
[...sort -M doesn't work the way I expect it to...]
Thanks for the report, but that's not due to a bug.
Two things might be causing trouble here:
- a common misunderstanding about how sort works with byte offsets:
without `-b' or the b attribute, each field includes leading d
Owen
> Strange:
> 'sort roadstmp1.17848' works on my Viglen Genie P3 650 running RedHat
> 7.1, linux 2.4.9
>
> but not on my Dual P3 1Ghz Caompaq ML 370 RedHat 7.1, linux 2.4.8. It
> segments returning 139 for $?.
Thanks for the report. However there are two things that could be
improved.
Bob Proulx <[EMAIL PROTECTED]> wrote:
> Peter
>
>> sort fails for me on the attached file. Here is all the version
>> information:
>
> Thanks for the report and for supplying all of the needed version
> information. That was great.
>
>> [urbi@lsec2 oracle]$ sort --version
>> sort (GNU textutils)
Peter
> sort fails for me on the attached file. Here is all the version
> information:
Thanks for the report and for supplying all of the needed version
information. That was great.
> [urbi@lsec2 oracle]$ sort --version
> sort (GNU textutils) 2.0e
>
> [urbi@lsec2 oracle]$ uname -a
> Linux lse
> bash$ sort -k 1,1rn -k 2,2 example
> bash$ sort --version
> sort (GNU textutils) 2.0a
> bash$ rpm -q -f `which sort`
> textutils-2.0a-2
>
> This is a vanilla redhat 6.2 system.
Your report matches a common pattern. Jim has previously answered
these reports with the following mail. Note that
Greg Lindahl <[EMAIL PROTECTED]> wrote:
| bash$ more example
| 109 bar
| 111 b
| 111 a
| 1 10
| 9 foo
| bash$ sort -k 1,1rn -k 2,2 example
| 111 a
| 111 b
| 1 10
| 109 bar
| 9 foo
|
| It seems that the "n" is making sort ignore the separator, so it sorts
| "1 10" as if it were the number 110. Tha
Oops! Sorry, I should have caught that. Thanks for your help. :)
paddy
On Mon, 11 Jun 2001, Bob Proulx wrote:
> > There seems to be a bug in 'sort' from textutils-2.0 in how it treats
> > non-alphanumeric characters: it ignores them by default when sorting. I
> [...]
>
> Your report matches a
> There seems to be a bug in 'sort' from textutils-2.0 in how it treats
> non-alphanumeric characters: it ignores them by default when sorting. I
[...]
Your report matches a common pattern. Jim has previously answered
these reports with the following mail. Note that some vendors set
those langu
Hi,
Sorry, I don't think I made my point too clear in my last post.
The output that I would have expected would have been something like this:
index.10html
index.11html
index.12html
index-11html
index10html
index11html
index12html
Ie, for the strings containing '.' to be grouped together, a
At 11:41 AM 5/27/2001 +0200, Jim Meyering wrote:
>Thanks for the report.
>I haven't heard of that bug before.
>In any case, it doesn't appear to be a problem in the latest test release:
>
> ftp://alpha.gnu.org/gnu/fetish/textutils-2.0.14.tar.gz
It may be a bug specific to RedHat 7.0. From the f
Robert Citek <[EMAIL PROTECTED]> wrote:
| I was working with sort and noticed that I got some errors when string
| lengths were multiples of 16. Here's a bash script to demonstrate the error:
|
| ( c="x"; list=""; length=0
| for length in $(seq 1 48); do
| echo "length == " ${length}
|
Dear Bob and Jim,
On january 11, 2001, I received mails from you both, stating more or less
the same (here, I quote Jim):
> "Henk M. Keller" <[EMAIL PROTECTED]> wrote:
> | [sort -n doesn't work]
>
> I've heard that RedHat introduced a bug that made `sort -n'
> malfunction in a version they distr
> Alas, I am afraid my sort problem is more serious than Jim's answer suggests:
> When sorting numerically, even *identical* lines pop up in different places
> in the output!
> Setting the environment variable LC_ALL does not change this behavior.
Up until your latest information your problem fit
"Henk M. Keller" <[EMAIL PROTECTED]> wrote:
| [sort -n doesn't work]
I've heard that RedHat introduced a bug that made `sort -n'
malfunction in a version they distributed. I believe they
have made a fixed release since then.
I suggest you upgrade or just get the latest test release
ftp://alph
Hello Bob,
On january 10, 2001, 11:07 Bob Proulx wrote:
> Thank you for your report. Jim has previously answered these reports
> with something similar to the the following reply.
Thanks for your very speedy reply on my email concerning a sort problem.
>From Microsoft, I would probably have
> I can not explain the behavior of the command "sort" as demonstrated in the
> following typescript:
Thank you for your report. Jim has previously answered these reports
with something similar to the the following reply.
Note that later versions of sort include the following warning.
*** WAR
Thanks for the report.
That is due to a bug in some Redhat-specific changes.
There has never been such a problem in the GNU releases.
FYI, here's the latest test release:
ftp://alpha.gnu.org/gnu/fetish/textutils-2.0.8.tar.gz
I've heard you can get an rpm with a fixed version.
You are using th
> Cc: [EMAIL PROTECTED]
> From: Jim Meyering <[EMAIL PROTECTED]>
> Date: 07 Nov 2000 13:11:09 +0100
> Lines: 9
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>
> | Thanks very much for your message. I have followed your advice and
> | have solved my problem satisfactorily. Neverthel
| Thanks very much for your message. I have followed your advice and
| have solved my problem satisfactorily. Nevertheless, assuming you
| have a say in future versions of SORT, may I suggest that an option be
| included so that SORT would adopt the standard ASCII ordering
| regardless of enviro
> Cc: [EMAIL PROTECTED]
> From: Jim Meyering <[EMAIL PROTECTED]>
> Date: 01 Nov 2000 18:10:31 +0100
> Lines: 35
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
>
> [EMAIL PROTECTED] (Ruy Exel) wrote:
> | I think I found a bug in "sort 2.0". It is folding lower case to
> | upper case
[EMAIL PROTECTED] (Ruy Exel) wrote:
| I think I found a bug in "sort 2.0". It is folding lower case to
| upper case characters even if the -f option is not present. In fact
| it does not seem possible to make it act as is the -f option is
| absent. Below you will find the transcript of a shell
Elon Portugaly <[EMAIL PROTECTED]> writes:
| I encountered a bug in sort (GNU textutils) 2.0a.
[...]
| sort does not correctly sort numerical fields:
|
| running 'sort -k1,1n' on the following input:
[...]
Thanks for the report.
That is due to a bug in some Redhat-specific changes.
There has nev
$ cat a
20
1
3
8
$ export LC_ALL=POSIX
$ echo $LC_ALL
POSIX
$ sort -n a
8
3
1
20
http://www.mail-archive.com/bug-textutils%40gnu.org/msg00106.html
Title: Re: bug in 'sort' with '-n' or 'n' options?
bug-textutils
"craig martin" <[EMAIL PROTECTED]> writes:
| I wrote yesterday that "the sort utility program (written by Mike Haertel) that
| came with my Red Hat LInux 6.2 (obtained about April 2000) and that is part of
| the GNU textutils 2.0a (December 1999) seems to have a fundamental flaw". I
| have found
"Daben Liu" <[EMAIL PROTECTED]> writes:
| I'm using the sort program on RedHat 6.1, Linux 2.2.12-20smp distribution.
| The sort program behaves weird.
|
| The problem is illustrated as below:
| > uname -a
| Linux piper 2.2.12-20smp #1 SMP Mon Sep 27 10:34:45 EDT 1999 i686 unknown
| > which sort
|
28 matches
Mail list logo
