3 ms·
On Linux you can use progress¹ for many of these use cases. By default it scans for running processes that you might want to know about, but you can also ask i
by JNRowe 7y ago
On Linux you can use progress¹ for many of these use cases. By default it scans for running processes that you might want to know about, but you can also ask it tell you about a PID with -p. It supports a -m[onitor] mode to report status until the command exits, and features some basic filtering options to ignore certain files.
You can also manually dig about in /proc/$pid/fd{,info}/ if you want something more fancy, like using gdbar² to display a graphical progress through files for a given process.
1. https://github.com/Xfennec/progress https://github.com/Xfennec/progress
2. https://github.com/robm/dzen https://github.com/robm/dzen
- tetris11 7y agoIts good but it suffers from the same slowdowns as htop when there are multiple operations happening as it crawls through /proc
- JNRowe 7y agoYeah, I'd recommend using the `-p $pid` option when you can. Not just because it doesn't need to scan all of /proc, like the -c[ommand] or default mode do, but also because it doesn't suddenly start listing other processes when you're in monitor mode. That said, sometimes it is nice to see the other commands pop up in monitor mode. For example, when the rate suddenly drops in a command that you care about then the other output will often show the culprits for you to `kill -STOP`.