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



Reply via email to