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
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils