Re: [FR] Display stderr contents after executing shell blocks (even when stdout :results output is requested) (was: Org 9.6-pre and Bash sessions)

[Samuel Wales]

long ago i made the contents of my shell blocks look like this:

{
  code
} 2>&1
:


On 10/28/22, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Sat, Oct 29, 2022 at 04:05:19AM +0000, Ihor Radchenko wrote:
>> Rudolf Adamkovič <salutis@me.com> writes:
>>
>> > Ihor Radchenko <yantar92@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.
>
> [...]
>
>> > 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.
>
> [...]
>
>> 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?
>
> My take as an Org user is that this makes a lot of sense. I don't know
> whether there is an elegant way to accomodate all the use cases in
> an elegant way, but to provide a concrete example where I'd have found
> it handy...
>
> While preparing a handout for an introduction to shell programming
> (at a very basic level), I wanted to embed little examples with
> their results. Org rocks at this kind of task.
>
> But in this case it's important to show everything the students are
> going to see. One could argue that the error part is even the most
> important.
>
> So what I needed was not only the stderr (optionally somehow separated
> from stdout -- optionally as someone would see it in some terminal
> session), but also all the above even when the exit code was nonzero.
>
> Ideally, a display of that exit code, too.
>
> I ended up massaging prologue and epilogue, which worked nicely,
> but sadly is language dependent for a set of concepts which are,
> one could argue, independent of the language [1].
>
> So yes, I would be thrilled by such a possibility.
>
> Cheers
>
> [1] These are OS conventions. So also a language of sorts, but at
> another level.
>
> --
> tomás
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com