Closed nvxxu2i closed 6 years ago
clux
commented
6 years ago Hm, I'm not sure. The split is a pretty well established pattern and sending warn + err to stderr is something that most applications and languages do already. Even the linked article doesn't seem to be against that.
The 2>&1 double redirect always seemed ok to me (even if I can never remember the precise syntax).
nvxxu2i
commented
6 years ago It seems that my intention was not clear, so I'm rephrasing it:
I do not want to use stdout for the diagnostics, only stderr.
As I saw earlier, Errors, and Warns go to stderr, but Infos, Debugs, and Traces go to stdout, and the second behaviour surprised me.
nvxxu2i
commented
6 years ago @clux might I ask you to take a look again? I would love to see this change in the upstream repository.
clux
commented
6 years ago Hey, sorry was a bit busy this week.
I'm still not really convinced though; stderr is generally nice to keep separated to bad events. I don't see why sending info, debug and trace message to it is a better idea. If you send all of these things to the same stream you don't get the ability to filter out the errors from the noise in your shell.
This current setup mirrors standard bash conventions, C++ use of cout vs cerr, and the nodejs console api. It feels like a more sensible default for a logging library without many features.
clux
commented
6 years ago You can now configure loggerv in version 0.6.0 and above to do what you'd like. Please consult the latest examples/docs :-)
Closing this now.
It was quite weird when I ran a program verbosely and the next program in the pipe did not expect those random diagnostics, and failed miserably.
Therefore I think we should always put these diagnostic messages to the stderr. (At least according to this: https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout)
This change is