[anned20]

Description from man page:

       pw  stands for Pipe Watch. This is a utility which continuously reads textual input from a
       pipe or pipe-like source, and maintains a dynamic display of  the  most  recently  read  N
       lines.

       If  pw  is invoked such that its standard input is a TTY, it simply reads lines and prints
       them in its characteristic way, with control characters replaced  by  caret  codes,  until
       end-of-file is encountered. Long lines aren't clipped, and there is no interactive mode.

       The intended use of pw is that its standard input is a pipe, such as the output of another
       command, or a pipe-like device such as a socket or whatever.  In this  situation,  pw  ex-
       pects  to  be  executed in a TTY session in which a /dev/tty device can be opened, for the
       purposes of obtaining interactive input.  The remaining description pertains to  this  in-
       teractive mode.

       In  interactive mode, pw simultaneously monitors its standard input for the arrival of new
       data, as well as the TTY for interactive commands.  Lines from standard input  are  placed
       into  a  FIFO  buffer.  While the FIFO buffer is not yet full, lines are displayed immedi-
       ately.  After the FIFO buffer fills up with the specified number of lines  (controlled  by
       the  -n  option)  then  pw transitions into a mode in which, old lines are bumped from the
       tail of the FIFO as new ones are added to the head, and refresh operations are required in
       order to display the current FIFO contents.

       The display only refreshes with the latest FIFO data when

       1.     there is some keyboard activity from the terminal; or

       2.     when the interval period has expired without new input having been seen; or else

       3.     whenever the long period elapses.

       In  other words, while the pipe is spewing, and there is no keyboard input, the display is
       updated infrequently, only according to the long interval.

       The display is also updated when standard input indicates end-of-data.  In this situation,
       pw  terminates, unless the -d (do not quit) option has been specified, in which case it pw
       stays in interactive mode. The the end-of-data status is indicated by the string EOF being
       displayed in the status line after the data.

[chris_wot]

How is this different to tail -f ?

[tyingq]

The "triggers" seem to be the difference. The video shows it tailing strace, and only waking up the display and dumping data when it sees the poll() system call in the strace output.

Then they show a fancier example of a specific pattern of recvmsg(11,...) happening a specific amount of lines below poll(). That ends up showing the flow of data to a specific socket.

Or without triggers, it only shows you the latest when you tap the space bar or some other key.

[kazinator]

pw has no tail -f functionality; it doesn't monitor whether a file that has reached EOF will start growing again. If you do pw < file, it will just read to the end and then exit. Or else stay running with pw -d, but without reading any more data. But it can make sense to do this:

  tail -f logfile | pw

the main behavior change that pw will introduce is that during periods when the logfile is rapidly growing, it will prevent spewage to the terminal. It will only update when there is a lull in in the output exceeding the short timeout (default: 1 s), or else once every long timeout (default: 10 s). (These values were hard coded at first, then they became command line options, then dynamically adjustable too).

The development of pw was inspired by a discussion in the GNU Coreutils mailing list by a user wanting behavior along these lines from tail itself.

Then the other feature ideas came.

For instance pausing: we can suspend the display indefinitely. With tail -f, that's easy: you can just kill it. You can't kill a program that's taking input from a pipe without breaking the pipe, though. You can pause the terminal output, but not indefinitely without causing a backlog that could block the producing application, and when you resume, all the backlogged spewage will show.

[dundarious]

I like the tool a lot. I think people are still generally a bit confused about what it is, and the beginning of the man page is quite mechanistic, describing the implementation and leaving it up to the reader to interpret why that is useful.

The reasons I like it are that it's "an interactive streaming text viewer", along the lines of a readonly text editor designed for presenting inhuman amounts of data in a way that's useful for us humans. Think of the times you want to use your favorite text editor to interactively search and inspect streaming data, but can't because the stream is continuous.

- doesn't stream characters to the screen so fast that humans can't read it

- allows for interactively searching the stream and showing context

- operates on a large ring buffer, so all of this can be done without ever attempting to read a fixed subset or the entire stream

It reminds me of what Casey Muratori did for refterm: https://youtu.be/hNZF81VYfQo

[larsrc]

It tries to not flood your terminal when you're not interacting with it. Could be good on a slow SSH link, for instance.