Hi,
alain.coch...@unistra.fr writes:
> Ihor Radchenko writes on Thu 26 Oct 2023 13:44:
>
> > I can now reproduce the problem locally.
> >
> > It boils down to
> >
> > (setq exit-status
> > (process-file shell-file-name input-file
> > (if error-file
> > (list t error-file)
> > t)
> > nil shell-command-switch command))
> >
> > that is an equivalent of
> >
> > bash -c bash /path/to/file-containing-the-source-code.sh
> >
...
> I am confused about what you specifically do to "evaluate the above".
> To start with, I have to use quotes to make your command be performed:
>
> bash -c "bash /path/to/file-containing-the-source-code.sh"
>
...
>
> But most importantly, the second line *is* produced, either if I use
> an SSH key for passwordless access or if I enter the password
> manually.
IIUC, the elisp expression:
(process-file "bash" "/tmp/test.sh")
is more equivalent to:
cat /tmp/test.sh | bash
i.e. the shell is getting the commands from stdin. Thus, any command
that uses stdin might change what gets executed or not.
I'm able to reproduce using the following minimal script, without
passwords nor SSH (where the cryptic first line closes stdin).
#+begin_src shell :results output
exec 0>&-
echo OK
#+end_src
The result is "OK" only when commenting out the first line; else, the
echo command is not executed (because stdin has been closed).
Here is an other example, where the second echo is eaten by the script
itself:
#+begin_src shell :results output
echo 1
read -p "Next command? " NEXT_COMMAND
echo 2
echo 3
#+end_src
#+RESULTS:
: 1
: 3
Bruno
