Re: bug in "sort -n -k1.4,1.2"

[Cliff Miller]

> Cliff Miller wrote:
> > hi,
> >
> > i have a bug to report in coreutils-7.4.  the problem occurs with
> > empty fields under -n/-g, specifically in sub-field specifications wher=
> e
> > end < start.  according to the docs,
> >
> >> If the start position in a sort field specifier falls after the end of
> >> the line or after the end field, the field is empty.
> >
> > "after the end field" seems a little unclear; i take it to mean
> > "after the end [position] of the field", i.e., lima < texta.
> 
> That is a little ambiguous. One could interpret that as
> only pertaining to the input data. I.E. one could give
> an error when the user specifies the end position before start.
> But I think from the existing code, your interpretation is correct.
> I also got some friends to check this on solaris and that
> just ignores the fields in this case.

the non-trivial case here is when -b is present in the form

        sort -k2.1b,2.3

where the start and end positions could be in either order depending
on the number of blanks that start field 2.

> > here is a patch.  one could also change the null-insertion code
> > in the numeric test branch, but it seems better to correctly set
> > lima and limb from the start.
> 
> I agree. I tweaked it a little, and added 2 tests.
> 
> patch is attached.
> 
> thanks!
> P=E1draig.

thanks,
-cliff