GNU bug report logs - #5958
Sort-8.4 bug

Previous Next

Full log

View this message in rfc822 format

From: pacman <at> kosh.dhis.org
To: eblake <at> redhat.com (Eric Blake)
Cc: Santiago Rodriguez <srodri <at> fi.upm.es>, 5958 <at> debbugs.gnu.org
Subject: bug#5958: Sort-8.4 bug
Date: Fri, 16 Apr 2010 19:08:55 -0500 (GMT+5)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.