Re: bash source code block: problem after ssh commands

[Bruno Barbier]

Hi Matt,

Thanks this summary and for working on this!

Just a few comments/corrections about some specific points, hoping it
might help.

Matt <matt@excalamus.com> writes:

>  ---- On Fri, 17 Nov 2023 10:20:28 +0100  Ihor Radchenko  wrote --- 
>
>  > This has nothing to do with Emacs comint and this is also not a bug in
>  > Emacs 
>
> Ihor, there were two claims made in the original report.  I was referring to 
> Claim 2.  That deals with M-x shell and therefore comint-mode.
>
> Regarding Claim 1:
>
> - Can anyone verify Claim 1?

I do: the file is created and the command "echo bar" is NOT executed.

Here is my code block and its results:

    #+begin_src bash :results output
      ssh phone "echo foo>foo_file"
      echo "bar"
    #+end_src

    #+RESULTS:

No results (the echo command is NOT executed).

The file "foo_file" is created on the remote; its content is "foo".

    #+begin_src bash :results output
      date
      ssh -n phone "ls -alh foo_file"
      ssh -n phone "cat foo_file"
    #+end_src

    #+RESULTS:
    : Sat Nov 18 08:33:59 CET 2023
    : -rw------- 1 u0_a256 u0_a256 4 Nov 18 08:26 foo_file
    : foo



> - What versions are people using?
>   + M-x org-version
>   + M-x emacs-version

    #+begin_src elisp
      (list emacs-version org-version)
    #+end_src

    #+RESULTS:
    | 30.0.50 | 9.7-pre |

    GNU/Linux gentoo
    
> ...

> * Comments about the claims:

> ** Comment 1.
> ...
> I am unable to reproduce the reported behavior (of
> "bar" not returning).  Instead, I get an ssh-askpass permission denied
> error, foo_file is not created, and "bar" is given as the result.  I
> do not see anywhere in the thread that the original claim was
> reproduced.

It seems your SSH failed to connect.  In that case, I cannot swallow the
second command; thus the command "echo bar" is executed.

I can reproduce what you see on my side if I force the connection to fail:

    #+begin_src bash :results output
      ssh WRONG_REMOTE "echo foo>foo_file"
      echo "bar"
    #+end_src

    #+RESULTS:
    : bar


>
> The thread preceded something like follows.
>
> Leo Butler suggested two work arounds:
>
> - add the -f to the ssh command


> - add a semi-colon and line continuation to the first line.
>
> Russell Adams suggested another work around:
>
> - add -n to the ssh command

That's the one I use; the option -n is enough for me ('-n' = Redirects
stdin from /dev/null). The option '-f' means SSH will go to background;
I'm not sure I want that.

> ...

> ... 
> He then proposes an experiment to close stdin.  To do this, he calls
>
>     #+begin_src shell :results output
>     exec 0>&-
>     echo OK
>     #+end_src
>
> He claims that "exec 0<&-" closes stdin.  I believe there is a typo.
> ...

You're right. Good catch, thanks!

Although it seems to work either way on my side.

    #+begin_src shell :results output
      exec 0<&-
      echo OK
    #+end_src

    #+RESULTS:

    #+begin_src shell :results output
      exec 0>&-
      echo OK
    #+end_src

    #+RESULTS:
    

> What Bruno writes corresponds to "closing output file descriptor 0".  I 
> honestly don't know what the difference is between an "output file 
> descriptor" and an "input file descriptor".  I had no luck finding this 
> information in man bash or info bash.
>

My point was: the commands are read the standard input, thus, any
command that modifies that standard input will modify what gets
executed.


> ...
> This is what we see in Org.  I'll be honest, though, I don't
> really know what to expect with exec 0>&- and exec 0<&-.  When I call
> them in the terminal, it kills the terminal.

Let's forget about 'exec 0<&-' (closing the standard input/outputs):
this is bringing other corner cases.  But, yes, I would expect a
terminal to close itself automatically if its input is closed.

> ...
> As far as I can tell, though, that's not what prevents "bar" from being 
> returned.  As far as I can reproduce, calling
>
>     #+begin_src bash :results output
>     ssh localhost "echo foo>foo_file"
>     echo "bar"
>     #+end_src
>
> *does* give "bar" for results even though it shouldn't.

Does it echo bar when the SSH connection succeeds too ?


Thanks again for working on this.


Bruno