Jim Meyering wrote:
For each fix, I usually try to determine when the bug was introduced
and mention that in NEWS.
Both of these date back to the very beginning, since sort from
textutils-1.13 (yes, I actually built it ;-) exhibits the same incorrect
behavior, and the code in that function
Pádraig Brady wrote:
I also noticed that freeBSD/Mac OS X use coreutils sort
so they have the same issue.
Also the i18n patch in fedora 8 at least seems
to be varying one of the problems somewhat:
upstream buggy coreutils:
$ printf a y\na z\n | sort -k1,1b #buggy
a z
a y
$
I've tweaked the patch a bit to simplify some code
and expect to push it soon.
Thanks to my friendly LUG I confirmed that solaris 9 and 10
behave as expected for these commands:
printf a a b\nz a a\n | sort -k2,3.0
printf a y\na z\n | sort -k1,1b
cheers,
Pádraig.
From
Pádraig Brady wrote:
I've tweaked the patch a bit to simplify some code
and expect to push it soon.
Thanks to my friendly LUG I confirmed that solaris 9 and 10
behave as expected for these commands:
printf a a b\nz a a\n | sort -k2,3.0
printf a y\na z\n | sort -k1,1b
cheers,
Pádraig.
Jim Meyering wrote:
Pádraig Brady wrote:
I've tweaked the patch a bit to simplify some code
and expect to push it soon.
Thanks to my friendly LUG I confirmed that solaris 9 and 10
behave as expected for these commands:
printf a a b\nz a a\n | sort -k2,3.0
printf a y\na z\n | sort -k1,1b
Pádraig Brady wrote:
...
- /* If we're ignoring leading blanks when computing the End
- of the field, don't start counting bytes until after skipping
- past any leading blanks. */
- if (key-skipeblanks)
-while (ptr lim blanks[to_uchar (*ptr)])
- ++ptr;
+ if (echar !=
For each fix, I usually try to determine when the bug was introduced
and mention that in NEWS.
Both of these date back to the very beginning, since sort from
textutils-1.13 (yes, I actually built it ;-) exhibits the same incorrect
behavior, and the code in that function barely changed between my
Davide Canova wrote:
It seems to be doing as you describe, plus if a b option is used in
POS2, it also eats the leading blanks in the field after (POS2 field if
.0 is specified, POS2 field + 1 if .0 is implied):
$ sort -k2b,3.0b
a a b
z a a
^D
z a a
a a b
The location of a
Pádraig Brady wrote:
I've looked at this a little more, and wow it's confusing.
I think the documentation is inconsistent at least wrt -kPOS1,POS2.C
For POS2.0 it says that it refers to the end of POS2 field.
In fact what the code seems to be doing is referring to the end
of field, POS2 - 1.
Pádraig Brady p...@draigbrady.com writes:
Can someone at least confirm that we (should) interpret
the a x input as having 2 fields, 'a' and ' x' ?
A field comprises a maximal sequence of non-separating characters and,
in the absence of option −t, any preceding field separator.
Andreas.
Hi, I hope you understand my English, I have some problem with the b
option of sort (Slackware 12.2, kernel 2.6.27.7-smp, Coreutils 6.12).
From the -k section of the doc:
a character position of zero in pos2 indicates the field's last
character. If ‘.c’ is omitted from pos1, it defaults to 1
Davide Canova wrote:
$ sort -k 1b,1b #1
a x
a y
a z
^D
a z
a y
a x
$ sort -k 1b,1.0b #2
a x
a y
a z
^D
a x
a y
a z
I'm confused by the first command output too.
I'm not sure what the code is trying to do.
It looks like if you do specify and end field,
but
12 matches
Mail list logo
