I installed the attached spelling fix to a comment in my previous patch.From 8c1a447a3790ec74ef919c60d46673e7be061c72 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 25 May 2022 11:49:13 -0700
Subject: [PATCH] maint: spelling fix
---
src/sort.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Thanks, Pádraig, for fixing that. And thanks, Larry, for reporting that.
The existing tests are sufficient to catch this.
Yes, evidently I forgot to run 'make check', which I usually do. I'll
try to not forget next time
I installed the attached further patches to (1) coalesce duplicate
On 25/05/2022 03:00, Larry Ploetz wrote:
I think I've found a bug in sort (git branch master). The --reverse flag
seems to be ignored when --keys are supplied.
larryp-MBP:bin larry$ ./sort --version
sort (GNU coreutils) 9.1.17-a351f
Copyright (C) 2022 Free Software Found
I think I've found a bug in sort (git branch master). The --reverse flag
seems to be ignored when --keys are supplied.
larryp-MBP:bin larry$ ./sort --version
sort (GNU coreutils) 9.1.17-a351f
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
I can't see us disagreeing with Debian. Perhaps you can file a bug report with
Debian and get them to switch to the algorithm you prefer.
On 11/6/2018 10:48 AM, Assaf Gordon wrote:
On 2014-08-01 3:38 a.m., Schleusener, Jens wrote:
I am not sure if it's a bug or not but for my application cases the
"sort" command with use of the very helpful option "-V" (natural sort of
(version) numbers within text) not always delivers the by
tags 18168 notabug
close 18168
stop
(triaging old bugs)
Hello,
It seems your message was lost and not replied to in 4 years.
Sorry about that.
On 2014-08-01 3:38 a.m., Schleusener, Jens wrote:
I am not sure if it's a bug or not but for my application cases the
"sort" command with use of the v
taining '|8|' to sort before the lines
containing '|82|', then you can't use plain sort (which is over the
whole line), but instead need to use various -k, -n, and -t options to
tell sort where the keys are separated and which keys to sort on, and
the fact that the keys should
Sorry maybe I didn't speak clearly, I want to sort on the whole line by
each character from left to right, not only the 5 fields。
And why I use the same command "sort test.txt" and same input
"test.txt" on the 2016 Mac pro or on the windows10 , the result both
are :
20171012|3|205
forcemerge 28846 28847
tag 28846 notabug
close 28846
stop
On 15/10/17 01:03, Tree Big wrote:
> Dear coreutils :
> I am a Research and Development Engineer in IT. I met a situation when I
> use “sort” command in Linux shell which could be a bug for the "sort"
> command. So I hope you read this emai
PL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and Paul Eggert."
I am not sure if it is a bug in "sort" command
is is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and Paul Eggert."
*I am not sure if it is a bug in "sort" command in Linux Shell or maybe
it's only my problems in using it.*
*So I a
On 25/11/16 18:50, Paul Eggert wrote:
> Pádraig Brady wrote:
>> for UBSAN we should probably build with
>> _STRING_ARCH_unaligned defined globally
>> to avoid warning for the cases we already handle.
>
> Yes. Translating this for non-experts: the problem here is a bug in the
> bug-finding procedu
Pádraig Brady wrote:
for UBSAN we should probably build with
_STRING_ARCH_unaligned defined globally
to avoid warning for the cases we already handle.
Yes. Translating this for non-experts: the problem here is a bug in the
bug-finding procedure, not a bug in GNU coreutils or in Gnulib.
Recen
On 25/11/16 06:18, Marcel Böhme wrote:
> Dear all,
>
> The following execution is flagged by UBSAN as undefined behaviour:
>
> $ echo 0 > a; printf "%0.s0" {1..58} >> a
> $ ./sort -R a
>
> UBSAN says:
> ../lib/md5.c:371:7: runtime error: load of misaligned address 0x7ffdfd45a10d
> for type 'con
Dear all,
The following execution is flagged by UBSAN as undefined behaviour:
$ echo 0 > a; printf "%0.s0" {1..58} >> a
$ ./sort -R a
UBSAN says:
../lib/md5.c:371:7: runtime error: load of misaligned address 0x7ffdfd45a10d
for type 'const uint32_t', which requires 4 byte alignment
So, the roo
On 04/04/2016 08:31 AM, Matthijs Nescio wrote:
Hi,
Indeed, setting the environment variable LC_ALL to C solves the
problem. Thank you. I am a satisfied long-time user of sort so I was
flabbergasted.
Yes, the locale can affect 'sort' in funny ways. Thanks for following
up. Closing the bug re
On 04/04/2016 04:46 AM, Matthijs Nescio wrote:
I seem to have detected a bug in sort. Can you confirm?
Certainly there is a problem in your 'sort' installation. Perhaps it
depends on the locale? Try setting LC_ALL=C in your environment.
I cannot reproduce the problem with coreutils
Hi,
I seem to have detected a bug in sort. Can you confirm?
~ $
~ $ sort --version
sort (GNU coreutils) 8.4
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to chan
Dear Assaf,
Thank You very much!!
We didn't read carefully enough the manual.
Best Regards,
Adrià
On 12/03/2015 06:18 PM, Assaf Gordon wrote:
tag 22084 notabug
close 22084
stop
Hello Adrià and Deimos,
On 12/03/2015 07:30 AM, Adrià Rovira wrote:
I noticed the reverse option is not correct
tag 22084 notabug
thanks
On 12/03/2015 05:30 AM, Adrià Rovira wrote:
> Dear GNU,
>
> I am using the sort command in (GNU coreutils) version 8.13
>
> I noticed the reverse option is not correctly applied if it has to sort by
> more than one column.
>
> This behaviour is corrected by forcing aga
tag 22084 notabug
close 22084
stop
Hello Adrià and Deimos,
On 12/03/2015 07:30 AM, Adrià Rovira wrote:
I noticed the reverse option is not correctly applied if it has to sort by more
than one column.
This is not a bug, but simply a usage issue.
The "sort --help" page states:
" ... OPTS is o
Dear GNU,
I am using the sort command in (GNU coreutils) version 8.13
I noticed the reverse option is not correctly applied if it has to sort by
more than one column.
This behaviour is corrected by forcing again the type of sort.
This happens with -n and -g.
Example:
echo -e "930 7.83\n930
1 (that is, sort the ENTIRE line as a last-resort key); and now
that you have the entire line involved, --check can indeed see an
out-of-order difference in the input.
>
> It seems to me both of situation is equal with relation of line key, why
> does the output is different?
The output di
Hello!
In sort man page nothing told about working sort --check with '--key'
option. IMHO this behaviour is strange:
This case is succeeded:
$ echo -e '1\t2\n1\t1' | LC_ALL=C sort --key=1b,1 --check --stable
--field-separator=$'\t'
But this (without option '--stable') is failed:
$ echo -
Thanks for the explanation. This solves my issue.
On Tue, Nov 11, 2014 at 12:40 PM, GNU bug Tracking System <
help-debb...@gnu.org> wrote:
> Your bug report
>
> #19021: Possible bug in sort
>
> which was filed against the coreutils package, has been closed.
>
> The ex
On 11/11/2014 11:27 AM, Leslie S Satenstein wrote:
[please don't top-post on technical lists - it makes it harder to figure
out what you are asking]
> Why not have used sort -t ',' -k 1n ?
>
>>
>> This results in line 7 being sorted incorrectly: sort -t , -k 1n < weird.csv
Are you asking th
Why not have used sort -t ',' -k 1n ?
Regards
Leslie
Mr. Leslie Satenstein
Montréal Québec, Canada
From: Eric Blake
To: Ben Mendis ; 19021-d...@debbugs.gnu.org
Sent: Tuesday, November 11, 2014 12:39 PM
Subject: bug#19021: Possible bug in sort
tag 19021 notabug
tag 19021 notabug
thanks
On 11/11/2014 09:39 AM, Ben Mendis wrote:
> http://stackoverflow.com/questions/26869717/why-does-sort-seem-to-sort-a-field-incorrectly-based-on-the-presence-or-absenc
>
> Data is here: https://gist.github.com/anonymous/2a7beb4871b25ae8f8b3
Thanks for the report. Rather
http://stackoverflow.com/questions/26869717/why-does-sort-seem-to-sort-a-field-incorrectly-based-on-the-presence-or-absenc
Data is here: https://gist.github.com/anonymous/2a7beb4871b25ae8f8b3
This results in line 7 being sorted incorrectly: sort -t , -k 1n < weird.csv
This produced the expected
Hi,
I am not sure if it's a bug or not but for my application cases the "sort"
command with use of the very helpful option "-V" (natural sort of
(version) numbers within text) not always delivers the by me expected
output.
Example input file (with four test cases):
1.0.5_src.tar.gz
1.0_src.
tag 18121 notabug
close 18121
stop
It was confirmed off list that this was a RAM issue.
On 07/28/2014 04:41 AM, Pádraig Brady wrote:
This case might be indicative of single bit errors in RAM,
as the difference between '|' and 'x' is only a single bit.
I would first eliminate that possibility with a RAM checker.
Good diagnosis, thanks. I use ECC RAM in machines I do nontrivial wor
On 07/28/2014 01:05 AM, Tom Bryant wrote:
> I issued a "sort -n hugeFile > sortedHugeFile" and it introduced a very
> occasional but destructive "x" in to the data.
>
> The original data consisted of numeric fields, separated by the vertical bar,
> "|", and +, - and spaces. It was 25861964610 b
I issued a "sort -n hugeFile > sortedHugeFile" and it introduced a very
occasional but destructive "x" in to the data.
The original data consisted of numeric fields, separated by the vertical
bar, "|", and +, - and spaces. It was 25861964610 bytes in size.
The final file had around 10 "x" ch
tag 14269 notabug
thanks
On 04/25/2013 01:10 PM, Bruce Culbertson wrote:
> Hi,
>
> I'm using sort(1) version 8.13 in Ubuntu. It is case-insensitive, which I
> think is a bug. For example, it sorts the list "A b C d" as "A b C d", not
> as "A C b d". There is a -f option to fold lower case to u
Hi,
I'm using sort(1) version 8.13 in Ubuntu. It is case-insensitive, which I
think is a bug. For example, it sorts the list "A b C d" as "A b C d", not
as "A C b d". There is a -f option to fold lower case to upper for
comparisons (i.e., to make sort case-insensitive, which seems to be the
def
Hi Eric,Padraig,Bob and Paul,
Erics recommendation solves my question.
Thanks you all for your assistance,
Terence
[WFUser@RHEL63TEMP3942 ~]$ ls -lsd --sort=time /tmp/.[!.]*; ls -ls --sort=time
/tmp
4 drwxrwxrwt. 2 root root 4096 Nov 19 16:05 /tmp/.ICE-unix
4 drwxrwxrwt. 2 root root 4096
On 11/23/2012 04:17 PM, Coffey, Terrence (Terrence) **CTR** wrote:
Hi Bob, Eric and Paul,
Thank you all for your quick responses. Due to time zone differences, I had
gone home so I did not see
your emails until this morning. I'm based in Galway, Ireland.
Hi Terrence,
The Irish Linux Users gro
#x27;C'
in your environment.
tag 12907 notabug
thanks
On 11/16/2012 11:06 AM, Coffey, Terrence (Terrence) **CTR** wrote:
> Hi,
> I think I might have located a bug. I'm using Redhat 6.3.
Thanks for the report. However, I suspect that you are hitting this FAQ, and
tag 12907 notabug
thanks
On 11/16/2012 11:06 AM, Coffey, Terrence (Terrence) **CTR** wrote:
> Hi,
> I think I might have located a bug. I'm using Redhat 6.3.
Thanks for the report. However, I suspect that you are hitting this
FAQ, and not a bug in sort itself:
https://www.gnu.o
tag 12907 + moreinfo
thanks
Coffey, Terrence (Terrence) **CTR** wrote:
> I think I might have located a bug. I'm using Redhat 6.3.
What locale are you using? You can print out your locale settings
with the locale command.
$ locale
Very often the locale is set to a "human" locale where case i
Most likely it's a locale problem.
Try "sort --debug" and try setting LC_ALL='C'
in your environment.
Hi,
I think I might have located a bug. I'm using Redhat 6.3.
I'm try to get a listing of dot file sorted by date and all other files sorted
by date. I'd like all the dot file to appears before all other files.
Initially I was testing on 6.2 and noticed that the .(dot) files were not
passed to so
tag 9740 notabug
thanks
On 10/12/2011 12:41 PM, Lluís Padró wrote:
I found a bug in the "sort" utility that happens under utf8 locales, though
no character beyond basic ascii is involved in it...
Thanks for the report; however, this is almost certainly a case of your
locale defining a differ
I found a bug in the "sort" utility that happens under utf8 locales, though
no character beyond basic ascii is involved in it...
I'm using "sort (GNU coreutils) 7.4" from package
"coreutils-7.4-2ubuntu3" on ubuntu lucid 10.04.03 LTS
Short reproduction of the error follows below.
thank you
"sort --help" says:
*** 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.
and this most likely explains your situation.
On 12/01/2010 06:44 AM, Kielbasiewicz, Peter wrote:
> Hello,
> there seems to be a bug in Ubuntu's 10.10 sort command.
> I suspect that it defaults to the -f option now which I think is wrong.
Thanks for the report. However, this is not a bug in sort, but a
problem of your cur
On 16/12/09 01:18, john blair wrote:
cat a | /build/toolchain/lin32/coreutils-8.2/bin/sort -V
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kernel-2.6.18-164.6.1.el5.x86_64.rpm
kernel-2.6.18-164.el5.x86_64.rpm
The result should be
kernel-2.6.18-164.el5.x86_64.rpm
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kern
Thanks for the replies.
Kamil, you are right. It works if I remove x86_64.rpm from the string.
--- On Wed, 12/16/09, Kamil Dudka wrote:
> From: Kamil Dudka
> Subject: Re: Possible bug in sort -V
> To: "john blair"
> Cc: bug-coreutils@gnu.org
> Date: Wednesday, Decemb
On 16/12/09 12:47, Pádraig Brady wrote:
If you look at that spec:
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
it says that letters sort before anything (including digits as I read it).
Ah only for portions with no digits.
dpkg --compare-versions pkg#.1 '>' pkga.1
On 16/12/09 01:18, john blair wrote:
cat a | /build/toolchain/lin32/coreutils-8.2/bin/sort -V
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kernel-2.6.18-164.6.1.el5.x86_64.rpm
kernel-2.6.18-164.el5.x86_64.rpm
The result should be
kernel-2.6.18-164.el5.x86_64.rpm
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kern
On Wed December 16 2009 02:18:58 john blair wrote:
> cat a | /build/toolchain/lin32/coreutils-8.2/bin/sort -V
> kernel-2.6.18-164.2.1.el5.x86_64.rpm
> kernel-2.6.18-164.6.1.el5.x86_64.rpm
> kernel-2.6.18-164.el5.x86_64.rpm
>
> The result should be
> kernel-2.6.18-164.el5.x86_64.rpm
> kernel-2.6.18
Steve Ward writes:
> On Tue, Dec 15, 2009 at 20:18, john blair
> wrote:
>
>> cat a | /build/toolchain/lin32/coreutils-8.2/bin/sort -V
>> kernel-2.6.18-164.2.1.el5.x86_64.rpm
>> kernel-2.6.18-164.6.1.el5.x86_64.rpm
>> kernel-2.6.18-164.el5.x86_64.rpm
>>
>> The result should be
>> kernel-2.6.18-16
On Tue, Dec 15, 2009 at 20:18, john blair wrote:
> cat a | /build/toolchain/lin32/coreutils-8.2/bin/sort -V
> kernel-2.6.18-164.2.1.el5.x86_64.rpm
> kernel-2.6.18-164.6.1.el5.x86_64.rpm
> kernel-2.6.18-164.el5.x86_64.rpm
>
> The result should be
> kernel-2.6.18-164.el5.x86_64.rpm
> kernel-2.6.18-1
cat a | /build/toolchain/lin32/coreutils-8.2/bin/sort -V
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kernel-2.6.18-164.6.1.el5.x86_64.rpm
kernel-2.6.18-164.el5.x86_64.rpm
The result should be
kernel-2.6.18-164.el5.x86_64.rpm
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kernel-2.6.18-164.6.1.el5.x86_64.rpm
Is i
> Cliff Miller wrote:
> > hi,
> >
> > i have a bug to report in coreutils-7.4. the problem occurs with
> > empty fields under -n/-g, specifically in sub-field specifications wher=
> e
> > end < start. according to the docs,
> >
> >> If the start position in a sort field specifier falls after the
Cliff Miller wrote:
>
> the non-trivial case here is when -b is present in the form
>
> sort -k2.1b,2.3
>
> where the start and end positions could be in either order depending
> on the number of blanks that start field 2.
Right, good point.
I've added a test for that case also and pushed
Cliff Miller wrote:
> hi,
>
> i have a bug to report in coreutils-7.4. the problem occurs with
> empty fields under -n/-g, specifically in sub-field specifications where
> end < start. according to the docs,
>
>> If the start position in a sort field specifier falls after the end of
>> the lin
Thanks for the analysis and patch!
I'll take a look at this this evening as
I've been looking at this area recently.
cheers,
Pádraig.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
hi,
i have a bug to report in coreutils-7.4. the problem occurs with
empty fields under -n/-g, specifically in sub-field specifications where
end < start. according to the docs,
> If the start position in a sort field specifier falls after the end of
> the line or after the end field, the fie
Jeff Lerman wrote:
> I note that in the manpage for the "sort" utility, the -k flag syntax
> claims that an "=" should be used between the flag and the argument(s).
>-k, --key=POS1[,POS2]
> start a key at POS1, end it at POS2 (origin 1)
> This is incorrect and results in an er
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jeff Lerman on 8/26/2008 10:48 AM:
> I note that in the manpage for the "sort" utility, the -k flag syntax
> claims that an "=" should be used between the flag and the argument(s).
Thanks for the report. However, this is a misunderstandi
Jeff Lerman wrote:
I note that in the manpage for the "sort" utility, the -k flag syntax
claims that an "=" should be used between the flag and the argument(s).
Quoting:
-k, --key=POS1[,POS2]
start a key at POS1, end it at POS2 (origin 1)
This is incorrect and results in a
I note that in the manpage for the "sort" utility, the -k flag syntax
claims that an "=" should be used between the flag and the argument(s).
Quoting:
-k, --key=POS1[,POS2]
start a key at POS1, end it at POS2 (origin 1)
This is incorrect and results in an error from "s
Eric Blake <[EMAIL PROTECTED]> wrote:
>>From edd292f8d4a5845bcc0d01ab080a6fc9f51a36fa Mon Sep 17 00:00:00 2001
> From: Eric Blake <[EMAIL PROTECTED]>
> Date: Mon, 18 Aug 2008 21:50:27 -0600
> Subject: [PATCH] sort: improve usage wording
>
> * src/sort.c (usage): Mention that -k defaults to end of l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 8/18/2008 10:25 AM:
>>> This question comes up frequently. Is there some wording we can use to
>>> make it more obvious that omitting POS2 implies end of line, while still
>>> being brief enough for --help output?
>> "...e
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Eric Blake wrote:
>> According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM:
>>> Thank you very much for the clarification, it makes perfect sense to me
>>> now - as I said I was surprised that I appeared to have found a bug.
>>>
>>> I have now reread th
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Eric Blake wrote:
>> According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM:
>>> Thank you very much for the clarification, it makes perfect sense to me
>>> now - as I said I was surprised that I appeared to have found a bug.
>>>
>>> I have now reread the
Eric Blake wrote:
According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM:
Thank you very much for the clarification, it makes perfect sense to me
now - as I said I was surprised that I appeared to have found a bug.
I have now reread the documentation and I still don't think it is
particularly cle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[re-adding the list]
According to [EMAIL PROTECTED] on 8/17/2008 10:07 PM:
>
> Thank you very much for the clarification, it makes perfect sense to me
> now - as I said I was surprised that I appeared to have found a bug.
>
> I have now reread the d
09:16,806, and 14:09:17,141) are incorrectly reversed
> in order so that the Exiting line comes before the Starting line - despite
> the -k9r sort key.
This is not a bug in sort, but a misunderstanding on your part. -k2
requests using as a key all text starting from the second field and end
Hi there,
I ran into a very surprising bug in the Windows cygwin sort routine:
I'm running GNU coreutils 6.9.92.4-f088d-dirtJanuary 2008 on Windows XP
Service Pack 2.
Using the source data:
2008-08-17 14:09:13,816 [RMI TCP Connection(5)-10.67.16.134] INFO
bnz.ib.util.logging.MethodEntryExitL
I noticed that ./sort -m --batch-size=18446744073709551617
was printing garbage as part of its diagnostic.
Here's the fix, along with a couple other improvements.
>From cd1f4bc1ecde1e7b313c1d0d587a07965d00d8b1 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Sun, 10 Aug 2008 1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Barry Finkel on 5/20/2008 2:43 PM:
| I have a file that does not sort properly in Ubuntu dapper.
| The "man sort" page has at the bottom
|
| sort 5.93 May 2006 SORT(1)
Consider upgrading; the lat
I have a file that does not sort properly in Ubuntu dapper.
The "man sort" page has at the bottom
sort 5.93 May 2006 SORT(1)
zztydid% cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=6.06
DISTRIB_CODENAME=dapper
DISTRIB_DESCRIPTION="Ubuntu 6.06.2 LT
Your question is essentially about the collation ordering of : and ,.
This depends on your locale settings, which I would expect you have
set up differently on the two systems.
Your problem is addressed in the coreutils FAQ. You can find that as
the #1 result with a web search;
http://www.gnu.o
Hi,
I seem to have encoutnered a strange issue when using sort. Here is the
incorrect output:
dragon /tmp> sort --version
sort (GNU coreutils) 6.9
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software. You may redistribute copies of it under the terms of
the GNU General Publ
Pádraig Brady wrote:
> [EMAIL PROTECTED] wrote:
> > I redirect the input to the same file as follows
> > $ sort testfile > testfile
> > the file suddenly gets empty.
>
> cat warns you, but the file is still truncated.
Perhaps sort should include the same warning? But by that time the
deed is alr
Pádraig Brady <[EMAIL PROTECTED]> writes:
> Generally you will want to use a temp file like:
>
> sort testfile > testfile.sort
$ sort -o testfile testfile
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerp
[EMAIL PROTECTED] wrote:
> Hello there.
> I think I have noticed a bug in 'sort' program, version 5.97.
> When I try to sort a non-empty file and I redirect the input
> to the same file as follows
>
> $ sort testfile > testfile
>
> the file suddenly gets e
Hello there.
I think I have noticed a bug in 'sort' program, version 5.97.
When I try to sort a non-empty file and I redirect the input
to the same file as follows
$ sort testfile > testfile
the file suddenly gets empty. I think the program should sort
the file and
redirects the f
"Béla Horváth" <[EMAIL PROTECTED]> writes:
> sort -t\ -k3 -k6n ts.txt
> k3 works fine, but k6 works not numerically. If I test only to sort for k6
The secondary key is ignored, because the primary key already provides
unique keys. Since you didn't specify the end point of the key it
defaults to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Béla Horváth on 8/9/2007 7:18 AM:
> I have a problem with "sort" (I tested it on ubuntu 7.04, on Mac OSX, and on
> AIX too, and they are identical)
Actually, this seems like a misunderstanding on your part as to how sort
works.
>
> I t
Dear All,
I have a problem with "sort" (I tested it on ubuntu 7.04, on Mac OSX, and on
AIX too, and they are identical)
I try to sort the attached file. Field separator is , but in the timestamp
field between date and time there is a , not a .
I have to sort as first key for timestamp (field 3
st likely, this is not a bug in sort, but a misunderstanding on your
part as to how locales affect sort.
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021
- --
Don't work too hard, make some time for fun as well!
Eric Blake
On 5/27/07, Weiping Shi <[EMAIL PROTECTED]> wrote:
Hi!
I noticed "sort" has a bug when sorting the atatched
example. In gneral, it treats blank/tab at the end
incorrectly, and get strange and untable results.
It happens in every Linux systems, from latest Fedora 6 to
Debian to old Mandrake Linu
Hi!
I noticed "sort" has a bug when sorting the atatched
example. In gneral, it treats blank/tab at the end
incorrectly, and get strange and untable results.
It happens in every Linux systems, from latest Fedora 6 to
Debian to old Mandrake Linux.
Thanks,
Weiping Shi
Texas A&M Universitynet1202
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please keep replies on the list, so that others can help, and so that your
solution can be archived for others to view.
According to Lukas Michelbacher on 2/3/2007 7:23 AM:
> Thank you for the quick reply. I upgraded to the latest version. Still
> the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Consider upgrading. Textutils was joined into coreutils, and the latest
version is now 6.7.
According to Lukas Michelbacher on 2/3/2007 6:32 AM:
> Hello,
>
> is this a bug?
>
> input:
>
> action non-intervention95.285097237109 0.000164853
Hello,
is this a bug?
input:
action non-intervention95.285097237109 0.000164853280580284
action punch 95.82548563298540.000439608748214089
action reasons 95.20568213276790.00175843499285636
output after sort command 'sort -r -g -k 3,3 ':
action reasons 95.2056821
John Novatnack wrote:
> I ran across strange behavior of the Unix sort command.
Thanks for the bug report. But as you know GNU is Not Unix. :-)
What version of GNU sort are you using?
sort --version
What is your locale setting?
locale
> But now see what happens when I add a trailing zero
I ran across strange behavior of the Unix sort command. Consider the
following example. First what I would call a correct sort.
$ sort -n
0.1 2
0.1 3
0.1 1
0.1 2
0.1 1
0.1 2
0.1 2
0.1 3
But now see what happens when I add a trailing zero.
$ sort -n
0.1 2
0.1 3
0.1 1
0.10 2
0.10 2
0.1 1
0.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to L.Palmerini on 10/13/2006 11:42 AM:
> Consider the email list in test1 (attacched)
>
> With some test You show sort coreutils bug.
>
> If You sort emails in test1
>
> sort test1 | less
Most likely, this is not
Consider the email list in test1 (attacched)
With some test You show sort coreutils bug.
If You sort emails in test1
sort test1 | less
You obtain
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[E
Simon Anders <[EMAIL PROTECTED]> writes:
> However, when two keys are present, this fails to work:
>
> $ sort -g
> [IN ] 5 2
> [IN ] 5 -3
> [OUT] 5 2
> [OUT] 5 -3
You are selecting the whole line as the sort key, and -g then instructs
sort to extract the leading numerical prefix from it
Hi,
either I misunderstand the documentation, or there is a subtle bug in
sort, when used with option '-g'.
As the minus sign ('-') has an ASCII value higher than the digits,
negative numbers end up after the positive ones, when using lexical (not
numerical) sort:
$ sor
lete environmental information. Thanks
> for your attention.
This is probably not a bug in sort, but a misunderstanding on your part.
You probably have your locale set to something that collates strings in a
manner that your provided input file is already sorted in that locale.
http://www.gnu.org
[EMAIL PROTECTED] wrote:
> I have found what appears to be a bug in gnu sort 5.2.1, under Linux.
> The attached file is in UNIX format (no carriage returns). It is -not-
> in sorted order. Running 'sort sort.txt' produces output in the same
> order, ie unsorted. If you have trouble reproducing t
I have found what appears to be a bug in gnu sort 5.2.1, under Linux.
The attached file is in UNIX format (no carriage returns). It is -not-
in sorted order. Running 'sort sort.txt' produces output in the same
order, ie unsorted. If you have trouble reproducing this, please get
back to me and I'
1 - 100 of 126 matches
Mail list logo
