Thanks for the report. It is most appreciated. However it matches a
very common problem signature which is not usually a bug in sort. (Or
ls either.)
David Klein wrote:
> tmp-> sort --version
> sort (GNU textutils) 2.0e
Ew, that is very old. But it is not the age of that code so muc
I noticed that sort sometimes sorts '-' before '1' and sometimes
after. Here is an example, together with relevant version numbers.
TIA, David.
Script started on Sun Jun 13 15:20:31 2004
tmp-> cat sort.ex1
1
-1
tmp-> cat sort.ex2
1,
-1
tmp-> sort sort.ex1
1
-1
tmp-> sort sort.ex2
-1
1,
tmp-> s
> 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
Hello,
I can't believe it, but the sort command appears to have a sorting bug!
I'm running version 2.0.14 on RedHat 7.3.
If I put these 3 lines in a file 'foo'...
packages/YCC Form.pm
packages/YCC/Form HistoryForm.pm
packages/YCC/Form PropertyForm.pm
and then type 'sort foo', I get...
packag
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
Some background information first:
$ uname -a
Linux tango 2.4.18 #4 Tue May 7 15:38:55 CEST 2002 i686 unknown
$ cat /etc/issue
Debian GNU 3.0 (Woody)
(but it occurs also with Red Hat 7.3, a.k.a. Valhalla)
$ sort --version
sort (GNU textutils) 2.0
Written by Mike Haertel.
Copyright (C) 1999
"Robert K. Nelson" <[EMAIL PROTECTED]> wrote:
> Program: sort (textutils)
> Version: 2.0.14
> Problem: the -n option doesn't appear to work correctly when character offsets
> are given in the -k field
>
> Example: give the command
>
> sort -n -k4.5
> where "bug" contains the following lines
>
> 0
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
Program: sort (textutils)
Version: 2.0.14
Operating System: Linux (RH 7.2 running the 2.4.7-10smp kernel)
Hardware: Dual Processor 400 MHz Intel P5
Problem: the -n option doesn't appear to work correctly when character offsets
are given in the -k field
Example: give the command
sort -n -k4.5
Sorting months (option 'M') with character positions only works in the first field.
root# sort --version
sort (GNU textutils) 2.0
Written by Mike Haertel.
Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warr
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
Hello,
sort fails for me on the attached file. Here is all the version
information:
[urbi@lsec2 oracle]$ sort --version
sort (GNU textutils) 2.0e
Written by Mike Haertel.
Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
on of sort that comes with textutils-2.0
or newer and have reported a problem whereby it is sorting in
some non-ASCII order.
That is due not to a bug in sort, but to the fact that you have
set environment variables that direct sort to use improper locale-
specific tables (you or your vendor hav
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
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. That doesn't seem to correspond
to the "info" page. It's OK without the "
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
> [...]
> 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 v
rouped together, and so on.
Thanks again,
Paddy
--
Paddy Doyle
Sysadmin, UCD Netsoc
On Mon, 11 Jun 2001, Paddy Doyle (Sysadmin) wrote:
> Hi,
> 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
Hi,
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
know there are the -d and -i options to restrict sorting to alphanumeric
characters, but '-d' seems to be turned on by default.
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}
|
Hello,
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}
list=${list}${c}
echo -ne "${list}~\n$
hi,
when i do a normal sort of a dictionnary
the shorter name should be before the longer but instead i get
HACHISH
HACHIS
where HACHIS should be before HACHIS?
sort GNU version 2.0
hope you can help
philippe
___
Bug-textutils mailing list
[EMAIL
Gnu-Guys:
I dunno, but somehow this looks like a bug to me.
Does this look like a bug to you, or am I making some bad assumptions
here...?
[systest@gumbum SortBugs]$ cat /etc/issue
Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14-5.0 on an i586
[systest@gumbum SortBugs]$
Here are the files to
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
> some non-ASCII order.
>
> That is due not to a bug in sort, but to the fact that you have
> set environment variables that direct sort to use improper locale-
> specific tables (you or your vendor have probably set environment
> variables like LC_ALL to en_US).
>
> You
Sirs,
I can not explain the behavior of the command "sort" as demonstrated in the
following typescript:
Start of typescript
Script started on Wed Jan 10 12:52:48 2001
demo$ uname -a
Linux pantarhei.ATComputing.nl 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
demo$ ls -l /bin/so
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
Here's the output of version 1.22:
% /r/bin/sort --version
sort (GNU textutils) 1.22
% cat foo
3
3
4
4
5
5
% /r/bin/sort -n foo
3
3
4
4
5
5
Here's the output of version 2.0a:
azimuth (iain) [38] % /bin/sort --version
sort (GNU textutils) 2.0a
Written by Mike Haertel.
Copyright (C) 1999 Free Sof
> 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
[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
Dear Maintainer of Gnu text utilities,
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
To whoever will get to fix this:
sort -n works great as long as there is something following the
number that is more than a carriage return.
Ex:
file 'a' contains
5
2
2
6
7
222
6
23
62
112
74
If we 'cat a | sort -n' we get :
6
2
5
74
6
222
7
112
62
23
If we put a little w
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 ch
Hi,
I encountered a bug in sort (GNU textutils) 2.0a.
Here is the output of 'sort --version':
"
sort (GNU textutils) 2.0a
Written by Mike Haertel.
Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warrant
This pretty much speaks for itself. I don't know what it says, though.
> uname -a
Linux marduk 2.2.16 #2 Tue Jul 25 16:41:24 EDT 2000 i686 unknown
>
> which sort
/bin/sort
>
> sort --version
sort (GNU textutils) 2.0a
Written by Mike Haertel.
Copyright (C) 1999 Free Software Foundation, Inc.
Yesterday I forgot to included the text test file for controlling the
sort program. Therefore now the same message but the textfile
included.
Working with sort using option -n gives unpredictable
results.
All three following sort commands give wrong (unexpected)
results:
sort -oout.out +
Working with sort using option -n gives unpredictable
results.
All three following sort commands give wrong (unexpected)
results:
sort -oout.out +0.7 -0.10 +0.94 -0.99n
sort.txt
sort
-oout.out +0.7 -0.10 +0.94 -0.99 -n sort.txt
sort
-oout.out +0.7 -0.10 -n +0.94 -0.99 sort.txt
The
com
$ 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
law". I
| have found that the problem is more basic than I realised.
You are using the version of sort that comes with textutils-2.0
or newer and have reported a problem whereby it is sorting in
some non-ASCII order.
That is due not to a bug in sort, but to the fact that you have
set
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 that the problem is more basic than I
reali
The example below exhibits a bug in "sort (GNU textutils) 2.0a"
as available in "Red Hat Linux release 6.2 (Zoot)" running on a
K7 processor.
The example appears to work fine in "Red Hat Linux release 6.1 (Cartman)"
where the relevant command is "sort (G
Sorry for polluting: I just verified that the sort bug I reported was
introduced by a patch RedHat applied to textutils-2.0a. The stock
textutils-2.0a does not have the bug.
Mate
--
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Hello!
If You do a sort -t "|" -k 2 on:
--
1739|10.41.4.66
1742|10.41.4.65
1744|10.41.4.69
1749|10.41.4.60
1752|10.41.4.62
1762|10.41.4.64
1768|10.41.4.67
1769|10.41.4.61
1770|10.41.4.63
1791|10.41.4.6
1805|10.41.4.68
--
you get this:
--
1791|10.41.4.6
1749|10.41.4.60
1769|10.41.4.61
1752|10.41.
. ]
You are using the version of sort that comes with textutils-2.0
or newer and have reported a problem whereby it is sorting in
some non-ASCII order.
That is due not to a bug in sort, but to the fact that you have
set environment variables that direct sort to use improper locale-
specific tables (y
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
/bin/sort
> cat doo
AC
+C
> sort doo
AC
+C
> cat foo
"Joseph A. Wiencko, Jr." <[EMAIL PROTECTED]> writes:
| Hello,
|
| I would like to report a bug in the sort routine.
|
| I have an application I am transitioning from another machine and
| operating system. The new OS uses the following sort routine:
| sort (GNU textutils) 2.0
| Written
55 matches
Mail list logo
