[jaggederest]

The old unix philosophy of "print nothing on success" looks crazy until you start trying to build pipes and shell scripts that use multiple tools internally. Also very quickly makes it clear why stdout and stderr are separate

[sgarland]

Also becomes rapidly apparent that most modern tooling takes an extremely liberal view of logging levels. The fact that you’ve successfully processed a file is not INFO, that’s DEBUG.

[adwn]

"Finished conversion of xyz.mp3 to xyz.ogg" is valuable progress information to a regular user, not just to developers, so it belongs in INFO, not DEBUG.

[sgarland]

I suppose this is subjective, but I disagree. If I want to know the status of each item, I’d pass -v to the command. A simple summary at the end is sufficient; if I pass -q, I expect it to print nothing, only issuing a return code.

[adwn]

> If I want to know the status of each item, I’d pass -v to the command.

I don't disagree. In my opinion, the default log level for CLI applications should be WARN, showing errors and warnings. -q should turn this OFF (alternatively, -q for ERROR, and -qq for OFF), -v means INFO, -vv DEBUG, -vvv TRACE. For servers and daemons, the default should probably be INFO, but that's debatable.

[titzer]

It never felt crazy to me, with the exception that are many situations where having progress and diagnostic information (usually opt-in) made sense.

I guess it comes down to a choice of printing out only relevant information. I hate noisy crap, like LaTeX.