Re: Feature request: --progress option to wc(1)

[Rob Landley]

On 11/15/24 09:40, Joakim Lindblad wrote:
> I'm often using 'wc' for stuff that takes a long time, e.g. 'tar -tf 
> big.tar | wc -l' to count the
> files in an archive.
> Here I am lacking some intermediate feedback from the process.

tar -tv big.tar | pv | wc -l

http://www.ivarch.com/programs/pv.shtml should be in most distro 
repositories.

> Does a "--progress" version of 'wc' exist?

No, because you stick another command into the pipeline that writes some 
form of progress indicator to stderr and passes along the data to stdout 
to do this sort of thing.

If you don't like pv busybox has a "pipe_progress" applet and toybox has 
a "count" command that do roughly the same thing.

Backstory: I submitted my local count.c to busybox in 2003 
https://lists.busybox.net/pipermail/busybox/2003-October/043590.html and 
they bikeshedded it into "pipe_progress" a few weeks later 
https://git.busybox.net/busybox/commit/?id=e9080c9f4170 which was such a 
silly name (plus needing to remember underscore-or-dash) that most 
distros went with "pv" instead...

> I am envisioning a continuous 
> count with a simple
> line-wise overwrite a'la '\r'.

That's generally what they do, yes.

My original count.c from 1999 just output a byte count to stderr for 
each read buffer it passed along, toybox's current "count -l" does a 
more detailed transfer rate per second with human readable units.

What everybody REALLY wants is progress bars, but in order to have a 
progress bar you need to know how much total data to expect, which is a 
bit of a problem dealing with pipe data from an arbitrary source. You 
can do a command line argument telling pv/count/pipe_progress how much 
to expect, but where do you get the value to put there?

> I fail to find the option, and I don't find the feature request rejected
> https://www.gnu.org/software/coreutils/rejected_requests.html#wc
>
> I could potentially volunteer to implement it (but am happy not to).

You probably don't want to reimplement it individually in every single 
consumer of data, the point of unix pipelines is to compose multiple 
commands that do parts of the task.

Rob