Re: bash source code block: problem after ssh commands

[Ihor Radchenko <yantar92@posteo.net>]

Max Nikulin <manikulin@gmail.com> writes:

> ...
> I have not expected this difference.
>
> dash reads a block from stdin (whole file in this case) and interprets 
> commands.
>
> BASH reads just the ssh command and executes it. SSH reads "echo done" 
> from stdin, so when control is returned to bash, stdin is exhausted and 
> no commands remain to execute by BASH. SSH can not "unread" part of 
> input not consumed by the remote command despite it might be possible in 
> the case of the regular file as stdin.
>
> Actually bash reads the whole script file as well when called as it is 
> shown above, but it calls lseek before executing ssh. To make difference 
> more apparent (e.g. for strace), force creation of pipe(7) for which 
> lseek is not supported
> ...
> I do not think it is an Org or an Emacs bug. It is rather POSIX vs. bash 
> vs. dash issue.

I still see it as a bug - what Org mode does to run the shell blocks is
not what users expect. _By default_, we _should_ produce more expected
behavior.

The observed inconsistency between different shells just indicates that
our approach with `process-file' should not be used as it leads to
potentially confusing results (they are not confusing only to people who
dig deeply into ssh, bash/dash/etc, and Org mode internals).

I cannot find any clear motivation behind using `process-file' + INFILE
in the git logs. I assume that it was used simply because it is easier
compared to trying to create and run temporary script file on remote
hosts.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>