Ihor Radchenko <yanta...@posteo.net> writes: > I do not think that it make sense to display that buffer when the code > finishes successfully. I can see this kind of behaviour > breaking/spamming automated scripts or export---code working in the > past may throw error output into unsuspecting users.
But the exit code has nothing to do with the standard error. Unix programs can, and often do, halt with non-zero exit codes while producing error output containing important information, such as deprecation warnings. Further, many programs use error output as the alternative "anything but the result" stream. Preserving user data, instead of trashing it, data does not count as "spamming ... unsuspected users". On the contrary! For example, I use a program for work that uploads data to a certain 3rd-party server. It exits with a zero code but also shows extremely important notices on error output. As an "unsuspecting user", if I used Babel to run the program, I would end up in a trouble. So, we should never implicitly trash user-generated data, let alone based on a "completely made up" belief that a non-zero exit code somehow implies "no important error output". It does not. (I speak only about Unix-like systems here. Perhaps on other operating systems, things work differently.) > I do not think that it is a good idea. Code block execution may > involve a whole chain of blocks when expanding references. If we wipe > the error buffer and multiple blocks are failing, some errors may go > unnoticed by the user. In that case, can we prepend a newline instead of appending it? That way, the tests would look "more normal" and the buffer content would have the content one would expect, with no "hanging whitespace". Rudy -- "Genius is 1% inspiration and 99% perspiration." p-- Thomas Alva Edison, 1932 Rudolf Adamkovič <salu...@me.com> [he/him] Studenohorská 25 84103 Bratislava Slovakia