bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sort "b" option in pos2 has strange effect


From: Davide Canova
Subject: Re: sort "b" option in pos2 has strange effect
Date: Wed, 04 Feb 2009 18:14:40 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20081209)

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. This is demonstrated like:

$ cat sort.test2
a a b
z a a
$ ./sort-dbg -k2b,3b sort.test2 #eword=3 here
z a a
a a b
$ ./sort-dbg -k2b,3.0b sort.test2 #eword=2 here
a a b
z a a

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 field-end is not affected by whether initial blanks are skipped, therefore a "b" option in POS2 should have some effect only if a non-zero '.c' character position is provided.

I don't know what's going on exactly thought as
as I don't know what's expected. It certainly seems buggy.

I tried to omit the ".0" AND the "b" option in POS2 in all our examples and I think what I get is the expected behavior. Specifying them shouldn't change anything.

thanks!
 DC




reply via email to

[Prev in Thread] Current Thread [Next in Thread]