Nice, but I wonder why the actual tools don't already include this.
I even recall cp having been patched with a progress bar maybe a decade back in Gentoo, but for some reason that didn't stick.
I even recall cp having been patched with a progress bar maybe a decade back in Gentoo, but for some reason that didn't stick.
It is an open question whether progress is 'interesting' or not. My own opinion is that it is not interesting if the operation is nearly instantaneous. If any operation can take more than 5 seconds, it should have a progress bar and an estimated time of completion.
Earlier versions of Windows did this very well. Often these progress bars were a joke, but sometimes they were useful. It gave us valuable input on whether there is enough time to go get a cup of coffee, which as we all know, is the most important question for us all.
Almost. For some reason the Win95 and Win98 installer needed 75% of the time to go to 99% and 25% of the time to go from 99% to 100%.
If an operation is silent and hogging my prompt without any indication what is going on, is stuck, is the speed too slow etc. it is simply frustrating.
What I was thinking of is, a user invoking a script interactively which happens to call a tool (like CURL) may not want to see curl's big progress song and dance for every HTTP call the script makes, though a user invoking `curl` literally, would likely appreciate it. But I think in both cases curl sees a TTY, right? Oops.
You imply a great point that at least doing `2>/dev/null` in those scripts is at least consistent, and I just need to make a better habit of doing so.
coreutils refused the patches as saying they are feature complete, whilst they dont have progress support, nor Unicode support. Stubborn
There are vast numbers of improvements to softwares that never get sent to the places where they will do the most good (or at least have a proper record of why they were rejected by their authors). A quick perusal of the bug trackers of Debian or Ubuntu will reveal tonnes of local patches that the original authors of the softwares often never even hear about.
Things don't "stick" often times simply because they get lost.
I was looking at something like that just the other day. Here's a bug report that describes a problem with "doas" not opening the controlling terminal to do its authentication dialogue. This is actually a problem with a package named LinuxPAM, and doesn't occur when "doas" uses OpenPAM or BSD Auth. It's LinuxPAM that's where the code in question is. Fixing LinuxPAM would improve the lives of everyone that uses LinuxPAM, because the behaviour of not allowing standard input through in a command pipeline is not confined to "doas" but affects everything that uses LinuxPAM to do login authentication.
But time and again stuff like this languishes in the wrong place, for years and decades.
* https://github.com/jarun/advcpmv
This one got lost because the original author's WWW site just vanished, according to the doco.
I think commands could have progress but only as explicit option. I wish curl and 'docker pull' didnt spew so much text by default, filling up so many jenkins server's disks.
curl -sS -w '%{http_code} %{http_version}' https://www.goog le.com -o /dev/null
https://everything.curl.dev/usingcurl/verbose/writeout
I’ve only recently had to use curl’s features more in-depth, so I’m still fascinated by its potential.
Creating ticket... (200 OK)
The philosophy surrounding these tools wouldn't lend well to each implementing that. Fortunately `pv` exists, is perfect for this use-case, and included in many distributions. :)
has been in my ~/.bashrc for the majority of my career for large file transfers.