But surely if you could send a SIGUSR1 and get the progress it would be useful. I won't always have the foresight to put the progress argument. Maybe I expected the task to be quick but it's not.
By the way, on versions that don't support status=progress (like busybox and the BSD versions), you can periodically send a USR1 signal to get a progress update.
`progress` (https://github.com/Xfennec/progress) and similar can be very helpful too depending on the backup utilities being used (in my case often involving rsync) even if the processes normally have everything set to quiet so no progress information is automatically forthcoming.
Is a more portable way to do that, as "status=progress" is a GNU modification to dd, as I recall. Of course the most portable is to use one of the POSIX mainstays like cat or cp.
That tells you something is happening, and how much has been done, but not how much work there is left to do, or how much back pressure (load) there is on the server side. Consequently you can't work out how far along the progress is or how long is left. If you assume that there'll be a consistent amount of progress you can guess, but for a large upload (eg gigabytes) you'll usually be wrong.
If the server could send data back to update the progress event it would be really nice. Right now though, that can't be done (as far as I know.. maybe there's a way now.. I haven't looked for years.)
I've wondered for a bit why in the Unix philosophy there isn't a standard /dev/progress or something for somewhat unified progress reporting already. It seems something that should be easy to standardize: make it append-only and take maybe a task name and a double [0, 1] (maybe, maybe optionally x of y counts, but a single double should be all you need). Let the terminal, the shell, and/or the GUI figure out how it wants to display things.
All of the major OSes today have some sort of dock/taskbar/activity panel standardized progress reporting API that is basically that simple, seems interesting we haven't pushed that idea back into the terminal. Makes you wonder what other sorts of GUI era pseudo-devices might be useful to add to Unix. In the other direction, imagine if some of these tools had been standardized as real devices in past terminals, like using something fun like an analog meter for progress operations.
reply