On 24/05/2009, Roland Mainz <roland.mainz at nrubsig.org> wrote: > > Hi! > > ---- > > [The following is either a PSARC or OS/Net gatekeeper question - I don't > know it exactly and therefore both end-up in the CC: field] > During PIT (=PreIntegration Testing) for ksh93-integration update2 > (which includes an opensource replacement for /usr/bin/tail and > /usr/xpg4/bin/tail (note that both are built from the same source) - see > http://arc.opensolaris.org/caselog/PSARC/2009/249/20090420_roland.mainz.2) > we hit a bug with "tail -r/+r" and during fixing it we've hit the > following issue: > > SXCE B110 tail(1) manual page defines "tail"'s "-r" option like this: > -- snip -- > -r Reverse. Copies lines from the specified starting > point in the file in reverse order. The default for r > is to print the entire file in reverse order. > -- snip -- > > PSARC/2009/249 defines it the same way but with a shorter description: > -- snip -- > -r, --reverse Output lines in reverse order. > -- snip -- > > Both AFAIK are thought that option "-r" works like "tail -<number> | rev > -l" ("rev -l" outputs the incoming lines in reverse order). The > /usr/bin/tail+/usr/xpg4/bin/tail commands in SXCE B110 does this > correctly when I use something like "-<number>r", for example: > -- snip -- > $ print "1\n2\n3\n4\n5\n6" | /usr/xpg4/bin/tail > -4r > 6 > 5 > 4 > 3 > $ print "1\n2\n3\n4\n5\n6" | /usr/xpg4/bin/tail -4 | rev > -l > 6 > 5 > 4 > 3 > -- snip -- > > All other combinations for "-<number>" are identical between "tail > -<number>r" and "tail -<number> | rev -l", too. > > > However this is _not_ true when I use "tail +<number>r" compared to > "tail +<number> | rev -l". In that case the output differs: > -- snip -- > $ print "1\n2\n3\n4\n5\n6" | /usr/xpg4/bin/tail > +4r > 6 > 5 > 4 > 3 > 2 > $ print "1\n2\n3\n4\n5\n6" | /usr/xpg4/bin/tail +4 | rev > -l > 6 > 5 > 4 > -- snip --
I agree that this is a bug in SunOS5 tail. OSX, AIX and FreeBSD tail +4r return identical output as tail +4 reversed. As a historical note, AIX uses the same OSF derived sources as SunOS5 but IBM fixed this bug in 5L years ago. -- Cedric Blancher <cedric.blancher at googlemail.com> Institute Pasteur
