[kazinator]

> 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.

[yjftsjthsd-h]

> 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.

[procflora]

Isn't this basically how more modern "chatty" CLIs use stderr? Put all the nice progress bars and emojis behind `if isatty(2)`? I thought so anyway, but I'll admit I've never actually looked at what npm, uv, etc. do.

[matheusmoreira]

That's the right approach. Output goes to standard output, and user facing messages go to standard error. That way output can still be piped or redirected while the program talks to the user, and messages can also be suppressed by redirecting to the null device.

I've always been annoyed by the fact file descriptor 2 is called the "error" stream. Should have been called the "user" stream.

[kazinator]

If a tool unconditionally produces diagnostics on standard error, whether there is an exceptional situation or not, I consider that poor behavior, contrary to the quiet tool philosophy from Unix.

Standard error is special output that the user should be able to somehow see (e.g. on a terminal) even if the regular output is redirected (as you note above).

That doesn't mean standard error is above the quiet tool guideline.

[roundabout-host]

Or the "status" stream (you can still redirect it and it is useful sometimes).

[cookiengineer]

> It would be nice to have an agreed-upon protocol for progress reporting.

That was initially USR1 and USR2 as process signals, well, at least across binutils and coreutils.

I just wish that UNIX architecture or POSIX would have been modernized since then, like with JSONL based process communication or similar things.

In Go I usually end up building my own JSONL protocol to marshal/unmarshal states between long running processes. Wish that could've been a POSIX standard.

[IgorPartola]

Lots of programs report progress when you send SIGUSR1 or SIGUSR2.

[XYen0n]

Although not a standard protocol, `OSC 9;4` can be used to display a progress bar in the terminal emulator.

[mr_mitm]

Maybe the PowerShell folks were onto something when they implemented seven different output streams [1]. But then again most users are utterly confused by this and just dump everything to the information stream when they should be using the output stream, making their code near impossible to reuse in an idiomatic way.

[1] https://learn.microsoft.com/en-us/powershell/module/microsof...