Pádraig Brady <p...@draigbrady.com> writes: > On 27/06/2025 20:16, Collin Funk wrote: >> Hi Jim and Pádraig, >> Jim Meyering <j...@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.
I didn't get far in implementing it. So I am not in any rush. > 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? This would probably require adding a '--tac-program=' option to tail in order to handle './configure --program-(prefix|suffix|transform-name)=' before and after install. See a similar fix I did for diffutils a while ago [1]. In that case '--diff-program=' was already supported so no big deal. But I don't really want to add '--tac-program='. Seems a bit awkward to me. Collin [1] https://lists.gnu.org/archive/html/bug-diffutils/2024-06/msg00016.html