Randall Hopper [EMAIL PROTECTED] [2002-08-31 14:57:05 -0400]:
|if LC_COLLATE is telling sort to sort differently then then it _must_
|comply.
|
|Actually sort just passes the problem off to the C library. The C
|library routine strcoll() does all of the work. It is useful to read
Hi Bob,
Thanks for the reply.
Bob Proulx:
|Randall Hopper [EMAIL PROTECTED] [2002-08-31 10:32:29 -0400]:
| The GNU sort command (textutils-2.1) by default does this:
|
| --ignore-case
| --dictionary-order
|
|Thanks for the report. But you are mistaken. That is not the default
The GNU sort command (textutils-2.1) by default does this:
--ignore-case
--dictionary-order
I want to disable this so it behaves like other UNIX sorts. The man page
does not describe how to do this, so I assume it isn't supported.
For example, when sorting directory listings, you end up
Randall Hopper [EMAIL PROTECTED] [2002-08-31 10:32:29 -0400]:
The GNU sort command (textutils-2.1) by default does this:
--ignore-case
--dictionary-order
Thanks for the report. But you are mistaken. That is not the default
behavior for sort. Sort only behaves that way if specifically
Date: Wed, 26 Jun 2002 16:00:03 -0400
To: [EMAIL PROTECTED]
From: Vivian Wang [EMAIL PROTECTED]
Subject: sort bug on 2.1.18-5.47
Hi,
I think this is a bug about sort.
When I sort:
O'BRYANT;1;
O BRYANT;2;
O'BRYANT;3;
I got the result is same as input file.
Can anybody mail me a good version
stefano federici [EMAIL PROTECTED] wrote:
It seems that the -f option (that is the ignore-case option) of sort doesn't
work with accented characters. For example the following command
sort -f -k1 input.txt output.txt
where input.txt contains:
È 1
à 2
è 3
will output the following
Bill Peeler [EMAIL PROTECTED] wrote:
there appears to be a bug in the sort program.
sort (GNU textutils) 2.0a
...
sort -t , tiny_in -k 2nbd,2nbd -k 3nbd,3nbd -k 4nbd,4nbd -k 5nbd,5nbd
i ran it and got the following output:
...
input file:
3,20020109184710,30,2405,94,test
there appears to be a bug in the sort program.
after inspection of the 23 meg file that i found the problem in,
it looks like all the records with a single digit for key 2 are sorted
first and then all the records with two digits for key 2, etc.
it also looks like there is a problem when you
Hi Tom,
[Bill, it looks like your problem is similar]
I think you're misreading the spec.
It says that if any per-key option is specified, then
that overrides all global ordering options for that key.
The following options shall override the default ordering rules.
When ordering options
$sort --version
sort (GNU textutils) 2.0.11
Written by Mike Haertel.
Copyright (C) 2000 Free Software Foundation, Inc.
Here is the problem:
$ sort a a.srt
$ sort -c a.srt
sort: a.srt:34: disorder: 2:1000.N_i_B_MED
--
Jan P. H. van Santen
- Director, Center for Spoken Language
Bernhard Kuemel wrote:
Hi!
Shouldn't sort without options sort by byte value? It seems to
skip leading white space. This is on mandrake 7.2 which IMO has
some other strange quirks.
[bernhard@b bernhard]$ sort
23
22^D
22
23
I now copied the good working version from my debian
Shouldn't sort without options sort by byte value? It seems to
skip leading white space. This is on mandrake 7.2 which IMO has
some other strange quirks.
Thanks for the report. It matches a common pattern. This is not due
to a bug, but to the fact that you or your vendor have set
Thanks for the report and patch.
That part of sort has been rewritten in recent test releases.
If you find that the latest version still has a problem,
please report it.
This is the latest test release:
ftp://alpha.gnu.org/gnu/fetish/textutils-2.0.14.tar.gz
Ketil Froyn [EMAIL PROTECTED]
Hi.
I have found a bug in sort. The bug is that if sort encounters a file
that already exists in the xtmpfopen() function, open() fails (because of
the O_EXCL flag). When cleanup() is called now, sort will wrongfully
delete the file that it encountered. I would like to propose this patch:
diff
GNU Sort seems to have a bug??? Here's the latest test:
If I replace 'thumbnail' with 'extension' then it works just fine. Also, if
you change "l" to "a" it works fine. Also, if you change "l" to "o" it still
fails.
It's as though the l or o is interpreted as 1 or 0, and then sorting breaks.
I'm using this version of sort:
[jan@razor /tmp]$ sort --version
sort (GNU textutils) 2.0.11
Written by Mike Haertel.
This file has been sorted:
b_1-a
b_1-a
b1-a
b_1-d
b1-d2
b1-d2
b1-d_2
b1-s
b_1-w
b_1-z
b1-z
Shouldn't the order be:
b1-a
b1-d2
b1-d2
b1-d_2
b1-s
b1-z
b_1-a
b_1-a
b_1-d
b_1-w
Jan Jannink [EMAIL PROTECTED] wrote:
| I'm using this version of sort:
|
| [jan@razor /tmp]$ sort --version
| sort (GNU textutils) 2.0.11
| Written by Mike Haertel.
|
| This file has been sorted:
|
| b_1-a
| b_1-a
| b1-a
| b_1-d
| b1-d2
| b1-d2
| b1-d_2
| b1-s
| b_1-w
| b_1-z
| b1-z
|
|
|
@localhost) by Sole.Stanford.EDU (8.8.8+Sun/8.7.2) with
ESMTP id MAA26444; Tue, 10 Apr 2001 12:13:44 -0700 (PDT)
Message-Id: [EMAIL PROTECTED]
To: Jim Meyering [EMAIL PROTECTED]
cc: Jan Jannink [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Jan Jannink [EMAIL PROTECTED]
Subject: Re: sort bug?
In-reply
Hello -
I've read the bugs archive and changelog on 2.0g
and tried compiling 2.0g to fix a sort problem,
but it still looks broken:
kadenix:~ cat sorttest
3
A
a
!
,
"
When I sort using 2.0 and 2.0g, I get:
kadenix:~ sort sorttest
,
!
"
3
A
a
Correct answer (works on 1.22):
[EMAIL PROTECTED] wrote:
| sort --version
| sort (GNU textutils) 2.0e
| Written by Mike Haertel.
|
| It places "@" ahead of "2"
|
| cat t.txt
| a
| 2
| @
|
| sort t.txt
| @
| 2
| a
You are using the version of sort that comes with textutils-2.0
or newer and have reported a problem whereby it
Hi,
The following:
sort mifluz.dict -t ' ' -k 2n,2n mifluz.dict.sorted
fails when mifluz.dict is large enough to trigger the use of
temporary files. Each temporary file is properly sorted by the resulting
output is *not* sorted numerically on the second field.
This bug only shows in
Thanks for the report.
I believe this is not a bug in sort.
This misunderstanding may be due to a weakness in the documentation.
The way sort's -b modifier works is different from the way any of the other
modifiers work in that it means different things when applied to the
field-start than when
22 matches
Mail list logo
