linux 5.8.1.arch1-1
pandoc 2.10.1-3
Up to a few weeks ago the output of --verbose would go to stdout, which seems to be normal practice for unix functions (rsync for example). Recently, that has quietly been changed, and the output of Pandoc's --verbose now goes to stderr along with any warnings.
For example, a test file bo.md containing this text:
Pandox XeLaTeX on U+2219, bullet operator, "∙", will trigger a WARNING for most fonts.
pandoc bo.md -o bo.pdf --pdf-engine=xelatex --verbose 2> stderr.txt
- nothing has gone to stdout, and stderr.txt now contains the output triggered by --verbose, followed by "[WARNING] Missing character..."
This seems to me to be a bug, albeit minor. Or is it an intentional feature going forward?
This was in response to #6483 -- maybe the change was ill-considered.
I didn't know there was any standard convention for verbose output.
Perhaps @garethstockwell who submitted #6483 would like to comment.
Btw, the change was not quiet: it is in the changelog:
+ Send verbose output to stderr, not stdout (#6483).
In my experience, command-line utilities are most useful if they follow the convention of all logging (of any type) going to stderr, and stdout being reserved for the command's _output_. If the command's output is intermingled with some logging / diagnostic messages, it interferes with one's ability to use the output in a structured fashion (e.g. to pipe it somewhere, like to a file, or to parse it). So I think #6483 was a positive change that should be preserved.
I definitely concur with @cjerdonek here, especially for a utility like pandoc that outputs content on STDOUT, all messaging from the utility that is not content should be sent to a different stream by default. The things being output by --verbose are not more verbose content, they are more verbose messaging. Whatever level whether errors or warnings or notices or debug messages, it all belongs on STDERR.
I agree and I'm going to close this.
Most helpful comment
In my experience, command-line utilities are most useful if they follow the convention of all logging (of any type) going to stderr, and stdout being reserved for the command's _output_. If the command's output is intermingled with some logging / diagnostic messages, it interferes with one's ability to use the output in a structured fashion (e.g. to pipe it somewhere, like to a file, or to parse it). So I think #6483 was a positive change that should be preserved.