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.
