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

[konsolebox]

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.
> >
> > If you mean that another `tail -f | grep` should run after first set
> terminates, ensuring proper continuity if even possible would still be
> difficult, and it will not work on streams.
> >
> > So far this is how I do it and it's awkward:
> >
> > tail -f /var/log/messages -n +1 | grep -e something > temp & pid=$!
> > inotifywait -mqq -t 1 temp
> > tail -f --pid="$pid" temp
> > rm temp
>
> Oh you want the timeout reset after any data is passed.
> I.e. only stop when no data has arrived within X seconds.
> The read(1) builtin may suffice for that?
>

Yes but only to hold initial display of lines and not bar new input.

   tail -f /var/log/messages -n +1 |
>    while IFS= read -r -t10; do printf '%s\n' "$REPLY"; done |
>    grep -e something |
>    tail
>

This excludes new incoming input after display.

If we added an option to tail(1) then it could be more flexible,
> like --max-wait-time=... to close/ignore a file after wait time
> has passed without any data, which would work with multiple files.
>

An option to wait for input to quiet down before displaying the last lines
among the ones currently received that is, but don't terminate and continue
displaying incoming new lines.

I'm not convinced such an option is warranted though
> given the external tools available to manage this.
>

The example I showed uses and manages a temporary file which is a major
inconvenience.  If input grows indefinitely so would the temporary file.
Inotifywait is also an additional dependency which could have been unneeded.

By the way I just noticed that the second tail would also have to have -f
as an option to imply that it still should output incoming data.  I'm sorry
that I haven't added it and probably caused confusion.

So initial example should have been:

tail -f /var/log/messages -n +1 | grep -e something | tail -f

Now if we add the option that I described above it should become something
like:

tail -f /var/log/messages -n +1 | grep -e something | tail -f -S 10

Also if "-S" is used without -f, behavior of tail can probably also work as
you described.  I.e., consider stream as closed after a few second of no
additional input.



--
konsolebox