|
|
|
|
|
by kazinator
1515 days ago
|
|
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. |
|
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