GNU bug report logs - #18808
tail: implement 'tail -r' as synonym for 'tac'

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 18808 <at> debbugs.gnu.org
Subject: bug#18808: implement 'tail -r' as synonym for 'tac'
Date: Thu, 23 Oct 2014 19:35:30 +0100

On 10/23/2014 05:53 PM, Eric Blake wrote:
> On 10/23/2014 10:39 AM, Eric Blake wrote:
>> POSIX is considering standardizing the Solaris/BSD behavior of 'tail -r'
>> rather than adding the GNU extension of 'tac' as a separate utility:
>> http://austingroupbugs.net/view.php?id=877
>>
>> This bug report serves as a reminder that we need to add 'tail -r'
>> support to coreutils, as well as a request for reviewers for the current
>> state of the proposal to make sure that it is not an onerous burden for
>> adding that code.
>>
> 
> Implementation-wise, I'm thinking the easiest thing might be to turn
> tac.c into a shared library-style file (similar to how copy.c is shared
> among multiple programs), add a 'tac -n' option that limits output to a
> fixed number of "lines" (or rather, a fixed number of occurrences of
> '--separator'-delimited segments), then have the new 'tail -r' call into
> the library code with separator hard-coded to newline, along with
> sufficient checks that tail's new -r can only be used with -n with no
> sign on the number (at least, as a first cut; we can certainly support
> more combinations than what POSIX wants to require, if we can determine
> sane semantics and easy implementations for those combinations).

The above approach sounds sensible if we were to do this.

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.

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).

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

Pádraig.

Previous Next

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