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

[Davide Canova]

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