GNU bug report logs -
#18808
tail: implement 'tail -r' as synonym for 'tac'
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On 10/23/2014 12:35 PM, Pádraig Brady wrote:
>
> Now the only reason I see would be for compat with solaris and BSD.
>
> I don't think they should have included that functionality though
> as there isn't much complementary with the other tail functions
> (being incompat with -f for example) and so is better split out as a separate util.
Yeah, today's Austin Group call included a debate about whether
standardizing 'tac' would be smarter than 'tail -r', but the consensus
among those on the call was that since:
1. more implementations already have 'tail -r' than 'tac'
2. standardizing new requirements to an existing utility is easier than
adding a completely new utility (if only slightly, due to less paperwork)
3. GNU code tends to be the most adaptable
therefore, 'tail -r' won the vote, and the result of the meeting was an
action to me to see how adaptable GNU really is, and whether we can
indeed quickly implement 'tail -r'.
>
> The only small advantage of integration is a tiny perf benefit
> when specifying a number of lines, but really `tail -r -n$num $file`
> is of minimal improvement over `tac $file | head -n$num`
> (though would be better than `tail -n$num | tac` as it avoids buffering).
The fact that we DON'T have 'tac -n' is what intrigues me most; that's
the one thing that 'tail -r -n' can do in a single process that GNU
can't. Of course, it is trivial to implement it by doing what tac has
always done and then stop output after -n is exceeded, and easy on
seekable files as well. But on non-seekable files, it may lend to an
interesting optimization where knowing that the output will be limited
to n lines makes it easier to set up a rolling window of the most recent
n lines seen rather than having to dump out to a temporary file when the
file proves to be larger than the current hueristics of when tac stays
in memory.
>
> As a side note I see that solaris doesn't even support non seekable input mode
> (though BSD does):
>
> $ printf "%s\n" 1 2 3 | tail -r -2
> tail: cannot open input
Careful, which tail are you testing? From your output, I'm guessing you
are trying to open the file named './-2' rather than limiting -r to a
line count. We made several observations during the Austin Group that
/usr/bin/tail and /usr/xpg4/bin/tail behave differently.
$ /usr/bin/tail -rc
usage: tail [+/-[n][lbc][f]] [file]
tail [+/-[n][l][r|f]] [file]
$ printf "%s\n" 1 2 3 | /usr/bin/tail -2r
3
2
$ printf "%s\n" 1 2 3 | /usr/xpg4/bin/tail -r -n2
3
2
$ printf "%s\n" 1 2 3 | /usr/xpg4/bin/tail -r -2
3
2
Curiously, Solaris usage also has a bug, as this command line SHOULD be
supported, per the output:
$ printf "%s\n" 1 2 3 | /usr/xpg4/bin/tail -r -c2
usage: tail [-f|-r] [-c number | -n number] [file]
tail [+/-[number][lbc][f]] [file]
tail [+/-[number][l][r|f]] [file]
But since it is not supported, the POSIX proposal does not require it,
and therefore, we don't have to worry about it either :)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 6 years and 243 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.