Ihor Radchenko <yanta...@posteo.net> writes:
> Rudolf Adamkovič <salu...@me.com> writes: > >> 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.) > > Dear All, > > As explained in the above quote, it may be reasonable to display stderr > in the shell (and possibly other) src blocks upon execution. > > + Stderr may contain important information even if the code block > succeeds > - Displaying stderr will raise *Error* buffer, which may or may not be > expected or desired. > > What do you think? I think this is perhaps the tip of a more complex iceberg. Not sure if we can address bits individually. Suspect we are better off clarifying the basic babel model and then look at specific language exceptions/limits and adjusting the model or documenting where back ends need to diverge from the basic model. Part of the challenge here is that the relevance/importance of stderr is somewhat dependent on the language. Same holds true for handling of error/return codes and to 'results' output. For me, this is another symptom of our need to define a clearer model for babel processes so that we can get some consistency across the board. Such a model would likely also make it easier for people to develop new babel back ends. We may even need 2 models, one for interactive/repl based back ends and one for non-interactive/scripted back ends. The 2 big questions I see are "What should be defaults be?" and "How do we handle the options without adding lots of new switches or suffering an option permutation blow out?". I do agree with the other posts regarding the importance of stderr.