Inconsistent terminal output routes re stdout and stderr

[stefanrueger]

The parms command in the terminal has always used the normal AVRDUDE messaging system, printing to stderr, and now follows the -qq reduction of what is printed. This means that the parms command can print nothing in the terminal:

$ echo parms | avrdude -p m328p -qqc arduino -t -P /dev/ttyUSB0
avrdude> parms

I think the terminal parms command should write to stdout (just like the other commands), and not follow the gradual reduction that -qq effects on the msg_level() system.

Trouble is that the library functions avr_display() and programmer_display() share the functions that the terminal parms command uses where we want gradual reduction with -qq.

In order to solve this discrepancy, we'd need to change the API for pgm->print_parm() to add a FILE * parameter that can be stdout or stderr.

Errors that happen in the terminal go partially to stdout (if the error is within the terminal parsing, eg) but errors of called library functions go to stderr. This is inconsistent. I suggest errors always go to stderr and normal (expected) terminal output goes to stdout. [edit - was already consistent, all errors go to stderr in terminal]

Thoughts?

[stefanrueger]

I suggest the following solution:

• Review use of terminal_message() in term.c and make the errors/warnings use the new msg_level() system
• Change the API of pgm->print_parm() to have an additional FILE * argument
• Extend the current msg_level() macros to pass on stdout/stderr, the line number and file name of the source
• Define and use fmsg_out(fp, ...) for printing to stdout/stderr and term_out to print to stdout
• Change terminal_message(MSG_INFO, ...) to a macro msg_error(...)

[stefanrueger]

See PR #1132

[mcuee]

Ref: PR #1132 should fix this. Unfortunately pulling in readline is a bit complicated under macOS and MSYS2 mingw.

• Revamp terminal output (progress bar, callback and stdout/stderr) #1132 (comment)