On Mon, Apr 25, 2022, 20:45 Pádraig Brady, <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 -- konsolebox
