GNU bug report logs -
#5958
Sort-8.4 bug
Previous Next
Reported by: srodri <at> datsi.fi.upm.es
Date: Fri, 16 Apr 2010 12:14:02 UTC
Severity: normal
Merged with 5991
Fixed in version 8.5
Done: Eric Blake <eblake <at> redhat.com>
Bug is archived. No further changes may be made.
Full log
Message #11 received at 5958 <at> debbugs.gnu.org (full text, mbox):
Eric Blake writes:
>
> On 04/16/2010 04:58 AM, Santiago Rodriguez wrote:
> > Dear sirs,
> >=20
> > I think I have found a bug in sort coreutils command. When I type
> >=20
> > sort -T /tmp +1 -2 +2rn -3 +0 -1<<EOF
> > perra/S perra 2.200000
> > perro/PS perra 4.400000
> > EOF
>
> Thanks for the report; however, this is not a bug.
>
> The syntax 'sort +1' is obsolete. You are better off rewriting your
When you pry it from my cold dead hands...
> scripts to conform to POSIX:
>
> sort -T /tmp -k2,3 -k3,4rn -k1,2
I don't think that's a correct equivalence. Traditional options +1 -2 should
mean the same as -k2,2 (i.e. the -2 means the key ends *before* field 2,
counting from 0).
Instead of comparing new coreutils to old coreutils, how about reading some
documentation that actually specifies the +pos1 -pos2 syntax, and is not
written from the "why won't those old people die off already" point of view?
For example the V7 man page:
http://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sektion=0&manpath=Unix+Seventh+Edition&format=ascii
Or something more recent, from Solaris, that provides a precise formula for
translating +pos1 -pos2 into -k options:
http://www.freebsd.org/cgi/man.cgi?query=sort&apropos=0&sektion=0&manpath=SunOS+5.10&format=ascii
--
Alan Curry
This bug report was last modified 15 years and 35 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.