Write CLI diagnostic messages to stderr

[lhark]

Description

All of the diagnostic and status messages in keepassxc-cli are now output to stderr instead of stdout.
Only meaningful data (data that might be piped to another process) like generated passwords or attributes retrieved with show is sent to stdout.

Motivation and context

Writing the prompt to stderr greatly helps with the use of keepassxc-cli in automated scripts or as a password provider for programs like mutt or borg.
This is done in accordance with POSIX that specifies that diagnostic messages be sent to stderr.
This commit should be a first step in solving the following issues: #831, #1221

How has this been tested?

Before the change, even the prompt goes to stdout:

$ keepassxc-cli show ~/test.kdbx "General/test" > /dev/null

After the change, only the attributes are sent to stdout:

$ build/src/cli/keepassxc-cli show ~/test.kdbx "General/test" > /dev/null
Insert password to unlock /home/lhark/test.kdbx:

To confirm I tried to use the new version to unlock a borg repo and it worked without any problems:

 $ BORG_PASSCOMMAND='build/src/cli/keepassxc-cli show /home/lhark/test.kdbx "General/borg" -a Password' borg list ~/test-repo
Insert password to unlock /home/lhark/test.kdbx:
2018-07-08T17:45:15                  Sun, 2018-07-08 17:45:20 [...]

Types of changes

• ✅ Bug fix (non-breaking change which fixes an issue)

Checklist:

• ✅ I have read the CONTRIBUTING document. [REQUIRED]
• ✅ My code follows the code style of this project. [REQUIRED]
• ✅ All new and existing tests passed. [REQUIRED]
• ✅ I have compiled and verified my code with -DWITH_ASAN=ON. [REQUIRED]

[TheZ3ro]

What about using qInfo? https://doc.qt.io/qt-5/qtglobal.html#qInfo

[lhark]

Reading the doc you provided, I get the feeling this function is more meant for debugging purposes. But now that you mention it, I see that qCritical() is used elsewhere in the code. At this point it is more a question of style than anything. For example, shoulld the password prompt be considered a debug output ?

I used QTextStream for stderr to stay consistent with the QTextStream used for stdout and stdin.

[TheZ3ro]

If we want to be meticulous we should use qCritical for errors and qInfo for other diagnostic messages. Anyway I think we can surpass this and approve the PR as is

[phoerious]

What gets actually printed to the screen also depends on your system's Qt debugging settings.

[droidmonkey]

OK, so we merged the new CLI STDIN/STDOUT/STDERR changes that @phoerious made. This directly conflicts with this entire PR. Can you please look at the new architecture and update your PR to fit?

I think it would be wise to redirect to STDERR only if a flag is set (ie, change the STDOUT to STDERR if --stderr flag is set). That way we can have the best of both worlds. Script friendly and user friendly.

[lhark]

I can make the changes, however I fail to see how using stdout by default is more user friendly. When an user is using the shell interactively, all messages from stderr are displayed on the terminal. And as I mentioned above only the actual result of a command is supposed to be output to stdout.

[droidmonkey]

That is fine, I agree with you.

invalid due to recent changes

[phoerious]

I don't think everything should go to stderr directly if it's not an error or a warning. A command that has output which may be piped must at least have an option for this behaviour (although I think that should rather be suppressing everything else), but just printing all diagnostics to stderr is probably not advisable. Various tools use stderr to detect errors in script execution (apart from checking the return value, which on its own may be misleading) and highlight stderr output differently from stout.

Suppressing diagnostics may also be in implicit option where the process checks if the target is a tty or not. If not, any non-result output is suppressed and password prompts should go to stderr, or course. Errors and warnings always go to stderr.

[lhark]

I didn't realize that the CLI tests were hidden with the GUI ones ^^
I can't finish fixing them right now, it'll be done in a few days.

[phoerious]

The CLI tests depend on some GUI routines for clipboard actions, so they need am X server to execute.