Hello,
I experiment with Nim code in Emacs/Org mode.
Org mode has an Org Babel feature that evaluates the code snippets and inserts the stdout results directly underneath them, given that that code snippet exited with a success exit code (0).
If there is an error (exit code > 0), the messages from stderr are sent to a separate "Org Babel Error" buffer.
All that is well.. but while playing with the unittest module, I saw that when the unittest tests failed, neither the under-the-code-blocks results drawer showed the error nor the dedicated separate buffer.
But from debugging the Org Babel, I could tell that the exit code of the failed test was in fact 1.
So this issue would occur only if unittest sent the error messages on stdout, but set the exit code to 1.
| Exit code | Output stream used | Problem? |
|---|---|---|
| 0 | stdout | No |
| 1 | stderr | No |
| 1 | stdout | Yes, unittest fails seems to be doing this. |
| 0 | stderr | Yes |
Here's the thread on the GitHub repo for the Org Babel package for Nim, ob-nim, that elaborates this further.
Anyone?
Is this a bug in unittest? Do I need to open an issue?
It's a tool that I am using that needs to distinguish the error messages from regular messages. As I tested, many other tools who rely on stdout/stderr would also fail, like the plain old shell indirection 2> vs >1.
I had later created issue #7913 for this.
Thanks.
I consider the distinction between stdout and stderr deeply flawed, but that's just me.
I believe the tools we use (like Nim) should be mostly interoperable with long-term convention, unless there's a real chance we could change the convention or if it's not needed to follow it. In this case, stdout and stderr (according to my quick google search) have been around since the 50's as a concept, so I doubt it's the proper hill to die on for Nim, although it is your language and invention, so you should be able to do as you please.