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

[Pádraig Brady]

Pádraig Brady wrote:
> 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 don't specify the .# part of it (as in the first
> example above), it bumps the end field up one?
> The line of code doing that is: http://url.ie/141l
> That in conjunction with skipping "ending blanks"
> is causing the issue I think.

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

Now one should never need to specify .0 so it seems to
me that it's an implementation detail that's leaked (incorrectly)
into the documentation?

I don't know what's going on exactly thought as
as I don't know what's expected. It certainly seems buggy.
The limfield function seems suspicious at least: hyyp://url.ie/15a7

Can someone at least confirm that we (should) interpret
the "a   x" input as having 2 fields, 'a' and '   x' ?

cheers,
Pádraig.