Re: Allow tail to display data after stream stops sending input after N seconds

[Rob Landley]

On 4/25/22 11:42, konsolebox wrote:
> On Mon, Apr 25, 2022, 23:56 Pádraig Brady, <P@draigbrady.com> wrote:
> 
>> On 25/04/2022 15:32, konsolebox wrote:
>> > On Mon, Apr 25, 2022, 20:45 Pádraig Brady, <P@draigbrady.com <mailto:
>> P@draigbrady.com>> wrote:
>> >
>> >     On 24/04/2022 11:45, konsolebox wrote:
>> >      > But this could work if there exists an option like -S which allows
>> >      > tail to wait for N seconds before considering input as "stopped"
>> and
>> >      > then displaying currently absorbed input.
>> >      >
>> >      > Current workaround would be to use a temporary file and use sleep
>> or
>> >      > maybe some repeated inotify checks before running second tail but
>> it's
>> >      > messy.
>> >
>> >     I'm not sure we need a separate option for this.
>> >     tail(1) will promptly act upon closed input,
>> >     so we can organize to close input upon a count
>> >     (with head -n, or grep -m), or after a time with timeout(1).
>> >
>> >     How about:
>> >
>> >         timeout 10 \
>> >         tail -f /var/log/messages -n +1 |
>> >         grep -e something |
>> >         tail
>> >
>> >     If that didn't suffice, you could organize things to
>> >     get the pid of a sleep process to pass to tail's --pid option:
>> >
>> >         sleep 10 & sleep_pid=$!
>> >         tail --pid=$sleep_pid -f /var/log/messages -n +1 |
>> >         grep -e something |
>> >         tail
>> >
>> >
>> > But the goal here is not to terminate "tail -f" after a few seconds but
>> limit filtered output to 10 lines and still keep reading incoming messages.

You asked for:

> allows tail to wait for N seconds before considering input as "stopped"
> and then displaying currently absorbed input.

Which is what Padraig offered, but what you seem to have actually WANTED was an
infinite wait for initial output, and then stop after 10 seconds of no
additional output. My quick-and-dirty suggestion off the top off my head was:

  input | while read $X i; do echo "$i"; X="-t 10"; done | output

I.E. an interposer that waits infinitely for the first gulp of data, and then
has a shorter timeout for additional data.

This seems like a thing you can easily do in an existing bash pipeline rather
than adding an option to a command that was in unix v7 and has somehow gotten by
without this for over 40 years? (And yes you can do byte at a time read/echo
instead of line at a time if that's what you want. Again, you didn't specify...)

Rob