Hi Matt,
Thanks this summary and for working on this!
Just a few comments/corrections about some specific points, hoping it
might help.
Matt <m...@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
