[Feature Suggestion] progress meter (pv subcommand) about toybox HOT 5 OPEN

So you want toybox's "count -l" to have an -L 8123748 variant so it knows how much data to expect and can do a progress bar and percentage complete?

As for "prior art", one of my first interactions with busybox back in the day was submitting my little "count" toy to them I'd been using since the 90's http://lists.busybox.net/pipermail/busybox/2003-October/043590.html and the immediate suggestion was of course to add a progress bar ala http://lists.busybox.net/pipermail/busybox/2003-October/043613.html and then there was bikeshedding on the list and the IRC channel and a fw weeks later the concept went in as https://git.busybox.net/busybox/commit/?id=e9080c9f4170 and then there was more bikeshedding I largely stayed out of because I'd been happy with "count"...

from toybox.

that is why i did not use the word "request" but rather "suggestion".

and i have to confess that i totally missed "count".

from toybox.

So you want toybox's "count -l" to have an -L 8123748 variant so it knows how much data to expect and can do a progress bar and percentage complete?

lets skip the discussion about a (graphical) progress meter a bit.

i have looked at count -l and it is a wonderful headstart i did not notice.

given that, a -L <expected-total> would be nice to show a "percentage complete".

looking at wc ... would it make sense to have an option to count lines (\n) instead ?
i have a number of use cases where a script reads line-wise from a file, calculating and showing progress.

from toybox.

You mean give count a line counting option? I could make -L do line counting and -p do progress bar, sure. Neither is hard, it's just... you listed 33 options for "pv" above and I'd like to know where the edges of the problem space are before extending much further. (Looks like pv uses -s for estimated size, might as well match that.)

Let's see...

-p and maybe -eI are implied by -s, -trab is default, -l you just requested and I guess -0 goes with that.

But -TA are silly, I'm not doing -F, -nwDiBC are micromanaging, what is -q FOR (don't put it in the pipeline then, cat exists), -wH have environment variables that already do that, -f implies that we care whether stderr is a terminal which is not currently the case, -E is similarly out of scope, -c is toybox policy, -RPd are just off in la-la land, and -hV have --long versions as part of default toybox plumbing so aren't an individual command's job.

You could make an argument for adding -LS (which would explain -q) but that's not really this command's job? Ratelimiting is usually bidirectional, so it's more a netcat -f thing? Hmmm. I suppose you could make the case that we've got the plumbing so it's cheap for us to do...

So maybe -sl0LSq options. And maybe test that "zcat blah | COLUMNS=47 count" works right, although defaulting to 80 seems pretty reasonable too...

P.S. I usually try to have this kind of discussion on the mailing list. Microsoft github will eventually go the way of all web services and this history will be lost, with no obvious standard export format to migrate the archive elsewhere.

from toybox.

i will subscribe

from toybox.