4 ms·

I think it is probably because of the UNIX philosophy of the virtue of silence: 'The program should say nothing if it has nothing interesting to say'. It is an

I think it is probably because of the UNIX philosophy of the virtue of silence: 'The program should say nothing if it has nothing interesting to say'. 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.

ElectricalUnion 3y ago
Earlier OSes and applications with only cooperative multitasking had to do this well; if a misbehaving application/operation was running it could just monopolize the system-wide event loop and stall the entire system.
hulitu 3y ago
> Earlier versions of Windows did this very well. 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%.
Yizahi 3y ago
For example Linux scp has progress bar and prints success results by default. I wish more tools did this.
Yizahi 3y ago
By the way, regarding Windows progressbars - even if a particular implementation is garbage, like for example passing to 50% instantly, then sitting there for a minute, then passing again to 75% and staying there and son on, they are still useful if your are using the same tool or operation repeatedly. My VPN progress indicator is junk, but I can roughly guess where is the problem based on where it got stuck now, simply because I've already saw multiple failure modes of it. Or if I'm installing some CPP distributives repeatedly, I can guess how long remains. 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.
xp84 3y ago
Another dimension is whether the (what is the correct noun here?) is a TTY or not. Arguably a progress display, especially one that deletes itself afterward, is a useful default when it's a TTY, but obviously it makes scripting annoying if you have to constantly add -q or -s (looking at you, CURL) to every command to shut it up.
- avgcorrection 3y ago
  Isn’t progress reported on stderr?
  - xp84 3y ago
    True, I think my phrasing/usage of terms was incorrect. I think my usage of "TTY" was incorrect. 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.
avgcorrection 3y ago
I think all Git commands show progress if they end up taking more than 2 seconds.

ElectricalUnion 3y ago

Earlier OSes and applications with only cooperative multitasking had to do this well; if a misbehaving application/operation was running it could just monopolize the system-wide event loop and stall the entire system.

hulitu 3y ago

> Earlier versions of Windows did this very well. 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%.

Yizahi 3y ago

For example Linux scp has progress bar and prints success results by default. I wish more tools did this.

Yizahi 3y ago

By the way, regarding Windows progressbars - even if a particular implementation is garbage, like for example passing to 50% instantly, then sitting there for a minute, then passing again to 75% and staying there and son on, they are still useful if your are using the same tool or operation repeatedly. My VPN progress indicator is junk, but I can roughly guess where is the problem based on where it got stuck now, simply because I've already saw multiple failure modes of it. Or if I'm installing some CPP distributives repeatedly, I can guess how long remains. 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.

xp84 3y ago

Another dimension is whether the (what is the correct noun here?) is a TTY or not. Arguably a progress display, especially one that deletes itself afterward, is a useful default when it's a TTY, but obviously it makes scripting annoying if you have to constantly add -q or -s (looking at you, CURL) to every command to shut it up.

avgcorrection 3y ago
Isn’t progress reported on stderr?
- xp84 3y ago
  True, I think my phrasing/usage of terms was incorrect. I think my usage of "TTY" was incorrect. 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.

avgcorrection 3y ago

I think all Git commands show progress if they end up taking more than 2 seconds.