From: Bruno Barbier <brubar.cs@gmail.com>
To: Matt <matt@excalamus.com>, Ihor Radchenko <yantar92@posteo.net>
Cc: "emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: bash source code block: problem after ssh commands
Date: Sat, 18 Nov 2023 09:19:13 +0100 [thread overview]
Message-ID: <65587383.5d0a0220.27bea.0b92@mx.google.com> (raw)
In-Reply-To: <18bdf538f2f.126bad4763316098.8581777358227217138@excalamus.com>
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
next prev parent reply other threads:[~2023-11-18 8:20 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 11:17 bash source code block: problem after ssh commands Alain.Cochard
2023-10-25 15:12 ` Leo Butler
2023-10-25 16:14 ` Alain.Cochard
2023-10-25 16:47 ` Leo Butler
2023-10-25 16:59 ` yaxp
2023-10-26 8:44 ` Ihor Radchenko
2023-10-26 13:23 ` Alain.Cochard
2023-10-26 13:44 ` Ihor Radchenko
2023-10-27 18:26 ` Alain.Cochard
2023-10-28 5:22 ` Max Nikulin
2023-10-30 10:50 ` Bruno Barbier
2023-11-06 13:32 ` Ihor Radchenko
2023-11-06 18:25 ` Matt
2023-11-07 8:55 ` Ihor Radchenko
2023-11-08 19:41 ` Matt
2023-11-09 12:14 ` Ihor Radchenko
2023-11-09 17:48 ` Matt
2023-11-15 16:32 ` Matt
2023-11-15 18:04 ` Matt
2023-11-16 9:32 ` Ihor Radchenko
2023-11-16 19:03 ` Matt
2023-11-16 19:46 ` Alain.Cochard
2023-11-16 20:54 ` Matt
2023-11-17 9:22 ` Ihor Radchenko
2023-11-17 9:55 ` Alain.Cochard
2023-11-17 10:17 ` Ihor Radchenko
2023-11-17 15:32 ` Leo Butler
2023-11-17 15:47 ` Bruno Barbier
2023-11-18 10:37 ` Ihor Radchenko
2023-11-21 19:01 ` Bruno Barbier
2023-11-22 17:06 ` Max Nikulin
2023-11-19 4:17 ` Non-emacs shell (Re: bash source code block: problem after ssh commands) Max Nikulin
2023-11-21 15:33 ` Bruno Barbier
2023-11-18 8:04 ` bash source code block: problem after ssh commands Max Nikulin
2023-11-18 10:43 ` Ihor Radchenko
2023-11-18 16:18 ` Max Nikulin
2023-11-17 22:07 ` Matt
2023-11-18 3:11 ` Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands) Max Nikulin
2023-11-18 8:11 ` Matt
2023-11-18 8:29 ` Bruno Barbier
2023-11-18 8:43 ` Matt
2023-11-18 8:54 ` Bruno Barbier
2023-11-18 9:09 ` Matt
2023-11-18 9:11 ` Bruno Barbier
2023-11-18 10:47 ` Ihor Radchenko
2023-11-18 8:19 ` Bruno Barbier [this message]
2023-11-18 9:02 ` bash source code block: problem after ssh commands Matt
2023-11-18 15:51 ` Matt
2023-10-26 14:44 ` Russell Adams
2023-10-27 11:47 ` Alain.Cochard
2023-11-06 18:01 ` Matt
2023-11-07 0:51 ` Alain.Cochard
2023-11-18 8:09 ` Max Nikulin
2023-11-18 8:36 ` Bruno Barbier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65587383.5d0a0220.27bea.0b92@mx.google.com \
--to=brubar.cs@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=matt@excalamus.com \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).