> A command is saying too little when it hangs for several minutes and the user starts to wonder if it’s broken.
Nope. For debugging the program, it is nice to have some debug tracing option, but if it's not the program's specification to produce output, it should not produce any. If the program's specification is that it produces a certain output after a certain calculation, then it shall not produce any other output, even if that calculation takes three weeks.
"cp -r from to" is supposed to be quiet until it's done or hits an error.
It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such). It's not bad; but fluff like this can't be in band with the output, or at least not by default.
> It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such).
Different thing, but I am reminded of the BSDs having SIGINFO.
> It's not bad; but fluff like this can't be in band with the output, or at least not by default.
FWIW, I would describe stderr as being out of band. IIRC that's how e.g. pv works; `<file.img pv | dd of=/dev/foo` sends data along stdout while giving status info to the user since stderr isn't being piped.
> A command is saying too little when it hangs for several minutes and the user starts to wonder if it’s broken.
Nope. For debugging the program, it is nice to have some debug tracing option, but if it's not the program's specification to produce output, it should not produce any. If the program's specification is that it produces a certain output after a certain calculation, then it shall not produce any other output, even if that calculation takes three weeks.
"cp -r from to" is supposed to be quiet until it's done or hits an error.
It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such). It's not bad; but fluff like this can't be in band with the output, or at least not by default.
> It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such).
Different thing, but I am reminded of the BSDs having SIGINFO.
> It's not bad; but fluff like this can't be in band with the output, or at least not by default.
FWIW, I would describe stderr as being out of band. IIRC that's how e.g. pv works; `<file.img pv | dd of=/dev/foo` sends data along stdout while giving status info to the user since stderr isn't being piped.