From: Max Nikulin <manikulin@gmail.com>
To: Matt <matt@excalamus.com>,
"emacs-orgmode@gnu.org" <emacs-orgmode@gnu.org>
Subject: Re: bash source code block: problem after ssh commands
Date: Sun, 30 Jun 2024 15:57:17 +0700 [thread overview]
Message-ID: <e42543d8-9075-4c6e-af82-21af744b00f7@gmail.com> (raw)
In-Reply-To: <18be3214fb5.c07a71b73414174.856693588849825524@excalamus.com>
On 18/11/2023 22:51, Matt wrote:
> ---- On Fri, 17 Nov 2023 23:07:57 +0100 Matt wrote ---
>> The second claim has nothing to do with Org Babel. I was able to
>> confirm it and provide the steps to reproduce. I think it would make
>> sense to report it upstream and let them decide if it's expected
>> behavior. I'm still happy to do that, but I need to step away from the
>> keyboard :)
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-11/msg00976.html
https://debbugs.gnu.org/67259
Notice that the report is for *interactive* sessions. Org babel sessions
are not so interactive. They are to maintain state, not to interact with
users directly. Consider
fakessh() {
bash -c 'read -t 10 -r; printf "fakessh read: %s\n" "$REPLY"';
}
fakessh
echo next
If you type them in terminal then result depends on delay between
"fakessh" and "echo next" commands. SSH is an example of command that
*may* read stdin while its command is running. To avoid ambiguity you
have to do either
fakessh </dev/null
echo next
or
fakessh <<"EOF"
echo next
EOF
"Reproducing" the issue in xterm-like applications or various emacs
shells makes things even more complicated. Result depends on TERM value
and if bracketed paste is enabled. With active bracketed paste shell
knows if you paste single line or a several lines into *shell prompt*,
so it does not feed second and following lines to first command stdin.
In the case of
#+begin_src bash :session *ob-shell*
bash -c 'read -t 10 -r; printf "read: %s\n" "$REPLY"'
echo next
#+end_src
comint can not guess if all lines are commands or some of them should be
considered as input to the previous command. Timing or bracketed paste
are irrelevant for ob-shell sessions.
Possible voluntary decision is to consider every session source block
similar to "C-x C-e" in bash prompt, so nothing should become implicit
stdin of commands. Content of a source block should be saved into a
temporary file then "source /path/to/block_content" command should be
send to the session buffer. Likely command depends on shell.
next prev parent reply other threads:[~2024-06-30 8:57 UTC|newest]
Thread overview: 67+ 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
2024-06-29 15:40 ` 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 ` bash source code block: problem after ssh commands Bruno Barbier
2023-11-18 9:02 ` Matt
2023-11-18 15:51 ` Matt
2024-06-30 8:57 ` Max Nikulin [this message]
2024-06-30 11:06 ` Ihor Radchenko
2024-06-30 15:19 ` Max Nikulin
2024-06-30 15:28 ` Ihor Radchenko
2024-06-30 15:48 ` Max Nikulin
2024-06-30 16:42 ` Ihor Radchenko
2024-07-01 9:41 ` Max Nikulin
2024-07-01 9:51 ` Ihor Radchenko
2024-07-01 10:54 ` Max Nikulin
2024-07-01 16:01 ` Ihor Radchenko
2024-07-03 11:06 ` Max Nikulin
2024-07-03 12:33 ` Ihor Radchenko
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=e42543d8-9075-4c6e-af82-21af744b00f7@gmail.com \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=matt@excalamus.com \
/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).