Re: bash source code block: problem after ssh commands

[Max Nikulin <manikulin@gmail.com>]

On 01/07/2024 16:51, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> My experience is that it is not easy to start a process without a tty in
>> Emacs. Eli will object.
> 
> I guess not on Windows (bug#71081). But otherwise I agree.

It was for starting mailcap viewer and Windows was not an issue.

> Although, I am not sure what we need to document and what we just need
> to rewrite.

I have posted it to this thread and to https://debbugs.gnu.org/67259

Some commands try to read standard input if it is available.  In 
interactive sessions it may be hidden due to time interval between typed 
commands.  Be careful when they are used in Org source blocks.
[[https://mywiki.wooledge.org/BashFAQ/089][BASH FAQ #89]]
warns concerning =ssh= and =ffmpeg=.  Either explicitly specify
=</dev/null= as input or use document here syntax.

#+begin_example
ssh example.org 'sed -i -e s/foo/bar/ file.txt' </dev/null
ssh example.org 'tee >>file.log' <<"EOF"
Added by org-babel
EOF
#+end_example

(Quotes around "EOF" suppress variable expansion in the text.)  Tools 
may have dedicated options, for example =ssh -n= is a more concise way 
to avoid the pitfall.

> In theory, we may work around all the pty-related problems
> by simply running a script file (that possibly also echoes its commands
> to keep them recorded for user examination).

Ideally some kind of bracketed paste should be added to `shell', 
otherwise it is insecure. However it is not an option for dash. I still 
have slight hope that implementation of =C-x C-e= might give another 
idea. Some subtle issues may arise with "source", but perhaps they are 
more rare than naive ssh usage. If you know how to add text to shell 
buffer without sending it to the process then you may try. I would leave 
an option to switch back to "direct" input.