On 10/24/2014 12:11 AM, Bernhard Voelker wrote:
> On 10/24/2014 12:52 AM, Eric Blake wrote:
>> On 10/23/2014 03:59 PM, Pádraig Brady wrote:
>> [...].  So among existing POSIX-certified systems, 'tail -r' is
>> the more popular extension at the moment.
>>
>>> Saying that, I'm 50:50 for implementing `tail -r` for compat reasons.
>>
>> Yes, this alone is reason enough to implement it in GNU, regardless of
>> the direction POSIX takes.
> 
> I'm also worried about such an extension.  'tail -r' might be a useful
> thing - when -r is the only option being used, but looking at all the
> other options GNU tail already got over the years, adding -r doesn't
> fit well.  You proposed to make -n available to tac and then jump into
> it from 'tail -r'.  Well, what about -c? --follow={name|descriptor}?

Reject them both.  Solaris 'tail -r' rejects use with -c or -f; reverse
mode is strictly limited to lines of a text file, and is strictly
limited to the existing end of the file at the time the command starts.

> --retry, --pid=PID?  To make -r fit well into tail, we'd have to add
> every single feature of it to tac.  This sounds not like a good idea.

No, to support 'tail -r', we make it refuse to operate with any option
other than -n, because that is all the more other implementations do,
and all the more POSIX is considering to require.  At least, as our
first cut at an implementation.  We can add more option interactions
later over time if desired as extensions, but we are not required to add
them, especially if we cannot come up with good semantics for those
interactions.

> tail does a good job, and so does tac.  I'd almost prefer to fork+pipe
> internally instead, similar to what e.g. 'sort --compress-program=PROG'
> does.

That's why my proposal is limited to just librar-ifying the tac.c code
and calling into it (no need to fork+pipe when we can just do the work
directly).


-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org