GNU bug report logs - #78910
tail does not support -r added by POSIX.1-2024

Previous Next

Full log

Message #20 received at 78910 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Collin Funk <collin.funk1 <at> gmail.com>, Jim Meyering <jim <at> meyering.net>
Cc: Eric Blake <eblake <at> redhat.com>, 78910 <at> debbugs.gnu.org
Subject: Re: bug#78910: tail does not support -r added by POSIX.1-2024
Date: Fri, 27 Jun 2025 23:21:31 +0100

On 27/06/2025 20:16, Collin Funk wrote:
> Hi Jim and Pádraig,
> 
> Jim Meyering <jim <at> meyering.net> writes:
> 
>>> tail -r comes from the BSDs.
>>> Also the BSDs don't have tac(1) which overlaps in functionality quite a bit.
>>> I'm a bit surprised -r was added by POSIX, but fair enough.
>>
>> "Surprised" is putting it lightly. I am disappointed and am tempted to
>> push back and to delay encumbering GNU tail with -r.
>> That is an option no GNU system needs, since they've all had tac since
>> before 1992-era textutils.
>>
>> I've Cc'd Eric Blake, in case someone wants to propose adding tac to
>> POSIX in spite of the fact that the BSDs still lack it.
> 
> Thanks for reminding me about 'tac'. For some reason I forgot about it.
> 
> That solves my question about how to implement 'tail -r' while avoiding
> arbitrary limits. But I agree that duplicating parts of 'tac' into
> 'tail' does not seem ideal.

Yes not ideal.

I wouldn't be rushing to implement it TBH.

Note the POSIX specified functionality is
limited to -n and a single file,
so we might be able to implement the POSIX subset
by just piping the output (of one file) to tac internally?

BSD functionality is more involved:

  $ seq 10 > a; cp a b  $ tail -n2 -r a b  ==> a <==
  10
  9

  ==> b <==
  10
  9

cheers,
Pádraig

Previous Next

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