Re: [BUG] ob-shell: :cmdline fails with single argument (was Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline)

[Matt]

  On Sun, 19 Nov 2023 07:57:26 +0100  Max Nikulin  wrote --- 

 > I would say that :cmdline is treated in a different way in comparison to 
 > :var:

It most definitely is.  It's a completely separate process from :var.

Re: [BUG] ob-shell: :cmdline fails with single argument (was Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline)

[Max Nikulin]

On 19/11/2023 01:20, Matt wrote:

#+begin_src bash :cmdline 1
echo "$1"
#+end_src

Then it fails with

list: Wrong type argument: sequencep, 1


I would say that :cmdline is treated in a different way in comparison to 
:var:


#+header: :results verbatim
#+begin_src bash :var arr='(1 2 3) :cmdline '(97 98 99)
  printf '$1:%s\n' "$1"
  declare -p arr
#+end_src

#+RESULTS:
: $1:abc
: declare -a arr=([0]="1" [1]="2" [2]="3")

I would expect more consistent results since script arguments is an 
array (positional arguments). $1=97, $2=98, $3=99

Non-emacs shell (Re: bash source code block: problem after ssh commands)

[Max Nikulin]

On 17/11/2023 22:47, Bruno Barbier wrote:

FWIW, M-x shell differs from what a plain terminal is doing (xterm, in
my case), but, I do prefer 'M-x shell' behavior: it allows me to copy
multiple lines, getting the same results as when I type them manually,
or copy them line by line. My xterm doesn't seem to allow me to do that.


I am unsure what do you expect from xterm, but perhaps it is not 
responsibility of a terminal application.


Multiple lines can be copied to regular BASH prompt (bracketed paste is 
enabled by default nowadays), however it may be inconvenient to edit.


You may use edit-and-execute-command (C-x C-e) (BASH, not Emacs key 
binding) to start an editor and to paste multiple commands there.


See also "fc" BASH built-in for editing and re-executing last commands.

Re: Suggestion: User-contributed use-cases on orgmode.org ?

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>>> Would it help if we change it to
>>>
>>> It is made of numerous .org files from https://git.sr.ht/~bzg/worg.
>>>
>>> ?
>>
>> Perhaps:
>>
>> Follow the link https://git.sr.ht/~bzg/worg for information (including
>> cloning) on the WORG Git repository at SourceHut (https://sourcehut.org).
>
> I am not sure if I like it.

Ok.  The more I look at it, the more I'm okay with it. I confused the
link to ~bzg/worg with an argument you would give to 'git clone', but
that's just me jumping to conclusions.

-- 
David Masterson

[BUG] ob-shell: :cmdline fails with single argument (was Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline)

[Matt]

  On Sat, 18 Nov 2023 16:54:39 +0100  Max Nikulin  wrote --- 

 > I have faced an inconsistency with :cmdline treatment in ob-shell.el. 

These are sadly easy to find.  

If you run:

#+begin_src bash :cmdline 1 
echo "$1"
#+end_src

Then it fails with 

list: Wrong type argument: sequencep, 1

However, running this works:

#+begin_src bash :cmdline "1" 
echo "$1"
#+end_src

I didn't dig too much into it, but it looks like :cmdline expects a sequence.  
When multiple arguments are passed, such as :cmdline 1 2 3, then "1 2 3" is 
passed into process-file.  (sequencep "1 2 3") is t.  (sequencep 1) is nil.  
So, to work around this a single :cmdline argument must be surrounded by quotes 
to make it a sequence.  (sequencep "1") is t.  Obviously, this should be fixed.

Attached is a patch to test for this whenever we're ready to tackle making 
execution mutually consistent.  I'm still reviewing the library and am not 
quite ready for that yet.

test-cmdline-with-single-argument-shouldnt-require-quotes.patch
Description: Binary data

Re: [BUG] ob-shell: :shebang changes interpretation of :cmdline

[Matt]

  On Sat, 18 Nov 2023 16:54:39 +0100  Max Nikulin  wrote --- 

 > I have faced an inconsistency with :cmdline treatment in ob-shell.el. I 
 > expect same results in the following cases:
 > 
 > #+begin_src bash :cmdline 1 2 3
 >printf "%s\n" "$1"
 > #+end_src
 > 
 > #+RESULTS:
 > : 1
 > 
 > #+begin_src bash :cmdline 1 2 3 :shebang #!/bin/bash
 >printf "%s\n" "$1"
 > #+end_src
 > 
 > #+RESULTS:
 > : 1 2 3

Thank you!  This makes a good test case.

Ihor or Bastion, Craig and my employer reached agreement on the disclaimer 
language.  I've sent a signed copy to Craig and haven't heard back yet with the 
go-ahead to continue contributing.  I sent the paperwork only a week or so ago, 
so I'm sure he'll get back to me in time.  Because of this, I'm including 
patches rather than pushing (which assumes I still have access (I haven't 
checked)).


test-cmdline-alone-and-with-shebang-have-same-result.patch
Description: Binary data

Re: bash source code block: problem after ssh commands

[Max Nikulin]

On 18/11/2023 17:43, Ihor Radchenko wrote:


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.


A shell without unexpected behavior is neither POSIX nor a descendant 
shell like BASH

https://mywiki.wooledge.org/BashPitfalls

Behavior if interactive and non-interactive shells is not the same anyway.


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.


From my point of view it is rather natural to use `process-file' since 
this function is available out of the box. I suspect some subtle issues 
may appear even if script file is forced.


On the other hand ob-shell already has a (bit buggy) implementation 
relying on script files. It is used when :stdin or :cmdline is specified.

[BUG] ob-shell: :shebang changes interpretation of :cmdline

[Max Nikulin]

Hi,

Trying to figure out the origin of the confusion with
"bash -c bash /path/to/file-containing-the-source-code.sh"
I have faced an inconsistency with :cmdline treatment in ob-shell.el. I 
expect same results in the following cases:


#+begin_src bash :cmdline 1 2 3
  printf "%s\n" "$1"
#+end_src

#+RESULTS:
: 1

#+begin_src bash :cmdline 1 2 3 :shebang #!/bin/bash
  printf "%s\n" "$1"
#+end_src

#+RESULTS:
: 1 2 3

Emacs-28, Org is the current git HEAD.

Re: bash source code block: problem after ssh commands

[Matt]

  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 :)

Submitted. 

https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-11/msg00976.html

Re: [BUG] https://tracker.orgmode.org/ is down (error 502)

[Bastien Guerry]

Ihor Radchenko  writes:

> https://tracker.orgmode.org/ 

Is up again.

> and https://updates.orgmode.org/ are
> currently down, both returning 502.

Is it necessary to bring updates.orgmode.org up?

-- 
 Bastien Guerry

[BUG] https://tracker.orgmode.org/ is down (error 502)

[Ihor Radchenko]

https://tracker.orgmode.org/ and https://updates.orgmode.org/ are
currently down, both returning 502.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Suggestion: User-contributed use-cases on orgmode.org ?

[Ihor Radchenko]

David Masterson  writes:

>> Would it help if we change it to
>>
>> It is made of numerous .org files from https://git.sr.ht/~bzg/worg.
>>
>> ?
>
> Perhaps:
>
> Follow the link https://git.sr.ht/~bzg/worg for information (including
> cloning) on the WORG Git repository at SourceHut (https://sourcehut.org).

I am not sure if I like it.

Consider the more complete context of this sentence as in
https://orgmode.org/worg/worg-about.html:

* What is Worg? What is its relation to Org?

Worg is a collaborative knowledge database about Org.

It is made of numerous .org files that you can clone from 
https://git.sr.ht/~bzg/worg.

...
* OK, I want to contribute to Worg now!

Your suggestion is going beyond the scope of "What is Worg?..." and goes
more into "I want to contribute to Worg", which is already quite
detailed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Ihor Radchenko]

Matt  writes:

> Evaluating the following 
>
> #+name: /tmp/test.sh
> #+begin_src bash :results output
> ssh localhost "echo foo>foo_file"
> echo "bar" | tee /tmp/bar.txt
> #+end_src
>
> does exactly what
>
> cat /tmp/test.sh | bash -c bash
>
> does.  Both create a file "foo_file" containing "foo" on the remote machine 
> and neither execute the second line.
>
> So, I would say that what happens in Org is the "expected" behavior.

Yup, it is expected. But only in a sense that "Emacs does what we asked
for when calling `process-file'". From the user point of view, it is not
expected at all. And, what is worse, may depend on (1) shell used; (2)
ssh config (see StdinNull in man 5 ssh_config).

I believe that we do need to change how we execute shell blocks _by
default_ - to something more predictable, like creating and running a
temporary script file.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: bash source code block: problem after ssh commands

[Ihor Radchenko]

Max Nikulin  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 .
Support Org development at ,
or support my work at 

Re: bash source code block: problem after ssh commands

[Ihor Radchenko]

Bruno Barbier  writes:

>> WRT M-x shell, feel free to submit a bug report. I mostly pointed that
>> the problem with M-x shell is not the problem you originally ran to. It
>> is a different problem (also, we ran into it in the past).
>
> FWIW, M-x shell differs from what a plain terminal is doing (xterm, in
> my case), but, I do prefer 'M-x shell' behavior: it allows me to copy
> multiple lines, getting the same results as when I type them manually,
> or copy them line by line. My xterm doesn't seem to allow me to do that.

The behavior of M-x shell can indeed be made use of.
However, this particular difference with xterm, AFAIU, is not
documented - unaware users may be surprised.
The situation is worse with Org shell blocks - users naturally expect
script-like behavior (even for :session), but run into edge cases like
this and get confused.

We should either document the caveats, or, preferably, make the behavior
more consistent with expectations. At least, by default.

That's why I think that filing a bug report makes sense from Org mode
project point of view.

> It looks like it is a known SSH "feature" (see
> https://unix.stackexchange.com/a/688024):
>
> #+begin_src bash :results output
> seq 100 | (ssh phone sleep 1; wc -l)
> #+end_src
>
> #+RESULTS:
> : 675173
> ...

> IMHO, what ob-shell is doing today seems a valid way of evaluating
> source blocks (and it seems to have been like that for a long time).  It
> should probably be documented somewhere, so that users know how to write
> their source blocks, or switch to another way, like adding a :cmdline
> parameter as mentionned in this thread.

And, as Max demonstrated, this ssh feature only works with bash, but not
necessarily other shells. Moreover, "-n" option that disables the above
may depend on ssh configuration (see StdinNull in man 5 ssh_config). So,
I believe that it only leads to confusion, even if we try to document
it.

__By default__, Org should produce more expected behavior - what users
would get from running a script file rather than from redirecting stdin.
We can optionally leave the stdin redirection as an option to be used by
the users who understand the peculiarities.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Bruno Barbier]

Matt  writes:

>   On Sat, 18 Nov 2023 09:54:46 +0100  Bruno Barbier 
>  
> It's still not clear to me if this is "what Emacs does".  However, that's the 
> best I could come up with.  
>
> Evaluating the following 
>
> #+name: /tmp/test.sh
> #+begin_src bash :results output
> ssh localhost "echo foo>foo_file"
> echo "bar" | tee /tmp/bar.txt
> #+end_src
>
> does exactly what
>
> cat /tmp/test.sh | bash -c bash
>
> does.  Both create a file "foo_file" containing "foo" on the remote machine 
> and neither execute the second line.
>
> So, I would say that what happens in Org is the "expected" behavior.

Agreed.

Re: Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Matt]

  On Sat, 18 Nov 2023 09:54:46 +0100  Bruno Barbier 
 
 > But, you're right.  To be safe, from now on, I'll use:
 > 
 > cat /tmp/test.sh | bash -c bash

It's still not clear to me if this is "what Emacs does".  However, that's the 
best I could come up with.  

Evaluating the following 

#+name: /tmp/test.sh
#+begin_src bash :results output
ssh localhost "echo foo>foo_file"
echo "bar" | tee /tmp/bar.txt
#+end_src

does exactly what

cat /tmp/test.sh | bash -c bash

does.  Both create a file "foo_file" containing "foo" on the remote machine and 
neither execute the second line.

So, I would say that what happens in Org is the "expected" behavior.

Re: bash source code block: problem after ssh commands

[Matt]

To clarify a previous typo I made.  Everything I've written was also done using:

1. emacs -q
2. C-x b "*scratch*"
3. M-x org-mode
4. Execute 

#+begin_src emacs-lisp :results none
(org-babel-do-load-languages
   'org-babel-load-languages
   '((shell . t)))
#+end_src

This corresponds to Org mode version 9.6.6 (release_9.6.6 @ 
/gnu/store/xjrhyapm3zwgpmq5baz6m9kavz287jjj-emacs-29.1/share/emacs/29.1/lisp/org/)

I had previously, and incorrectly, given my version used with my full init 
(which uses a different Org version).

  On Sat, 18 Nov 2023 09:19:13 +0100  Bruno Barbier 
 
 > It seems your SSH failed to connect.  In that case, I cannot swallow the
 > second command; thus the command "echo bar" is executed.
 > 
 > I can reproduce what you see on my side if I force the connection to fail:
 > 
 > #+begin_src bash :results output
 >   ssh WRONG_REMOTE "echo foo>foo_file"
 >   echo "bar"
 > #+end_src
 > 
 > #+RESULTS:
 > : bar
 
Thank you!  That makes sense.   I forgot that without set -e Bash keeps 
evaluating when errors happen.

Yes, once it connects, I get the same behavior as reported.

Here is how I connected without a password prompt:

1. ssh-keygen with id_babel, , 
2. cat ~/.ssh/id_babel.pub >> ~/.ssh/authorized_keys
3. chmod og-wx ~/.ssh/authorized_keys
4. ssh-add .ssh/id_babel

Re: Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Bruno Barbier]

Matt  writes:

>   On Sat, 18 Nov 2023 09:29:56 +0100  Bruno Barbier 
>
>  > IIUC, what Max is saying is that you should not concentrate on
>  > *that specific command* because that command doesn't do what you think
>  > it does.
>
> Cool, it sounds like we're agreed (albeit for different reasons).

Great :-)


>  > To reproduce, I'm personally still using:
>  > 
>  > cat /tmp/test.sh | bash
>  > 
>  > which is, IIUC, what:
>  > 
>  > (process-file "bash" "/tmp/test.sh")
>
> Yes, agreed.  I think that's more like what's happening.  
>
> What about the ("-c" "bash") passed into process-file?  

Useless indirection when the command is "bash" is the same as
'shell-file-name', like in our case ?

Maybe ...

But, you're right.  To be safe, from now on, I'll use:

cat /tmp/test.sh | bash -c bash


Thanks.

Bruno

Re: Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Matt]

  On Sat, 18 Nov 2023 09:29:56 +0100  Bruno Barbier 

 > IIUC, what Max is saying is that you should not concentrate on
 > *that specific command* because that command doesn't do what you think
 > it does.

Cool, it sounds like we're agreed (albeit for different reasons).  

 > To reproduce, I'm personally still using:
 > 
 > cat /tmp/test.sh | bash
 > 
 > which is, IIUC, what:
 > 
 > (process-file "bash" "/tmp/test.sh")

Yes, agreed.  I think that's more like what's happening.  

What about the ("-c" "bash") passed into process-file?  

The whole call looks like this:

(process-file
   "bash"
   "/tmp/two-lines.sh"
   '(t "/tmp/babel-mS0Yyg/ob-error-AoxNqH")
   nil
   "-c" "bash")

Re: bash source code block: problem after ssh commands

[Bruno Barbier]

Max Nikulin  writes:

> On 25/10/2023 18:17, alain.coch...@unistra.fr wrote:
>> By contrast, it works with this one:
>> 
>> #+begin_src bash :results output
>> sshcoch...@fruc.u-strasbg.fr  "echo foo>foo_file" ; echo "bar"
>> #+end_src
>
> What about
>
> #+begin_src bash :results output
> ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file" ; echo "bar"
> echo more
> #+end_src
>
> ?

For me:

 #+begin_src bash :results output
 ssh phone "echo foo>foo_file" ; echo "bar"
 echo more
 #+end_src

 #+RESULTS:
 : bar

And, telling SSH to not swallow the remaining commands (option '-n'):

 #+begin_src bash :results output
 ssh -n phone "echo foo>foo_file" ; echo "bar"
 echo more
 #+end_src

#+RESULTS:
: bar
: more


Bruno

Re: Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Bruno Barbier]

Matt  writes:

>   On Sat, 18 Nov 2023 04:11:03 +0100  Max Nikulin  wrote --- 
>
>  > >  bash -c bash /tmp/two-lines.sh
>  > 
>  >  From my point of view it was a plain mistake in attempts to simulate 
>  > the issue outside of Emacs. There is no point to concentrate on this 
>  > command. I tried to explain that it is incorrect usage of "-c" shell 
>  > option and what is the actual effect of this call, but I seems I failed.
>
> As an ob-shell user, my expectation is that execution within Org produces the 
> same behavior as outside of Emacs.  This is why I've focused on the command.  
> It acts as a guide for what is "correct."  Maybe this is misguided for a 
> reason I don't yet see?

IIUC, what Max is saying is that you should not concentrate on
*that specific command* because that command doesn't do what you think
it does.


To reproduce, I'm personally still using:

cat /tmp/test.sh | bash

which is, IIUC, what:

(process-file "bash" "/tmp/test.sh")

is doing, that is:

   The program’s input comes from file INFILE


Bruno

Re: bash source code block: problem after ssh commands

[Bruno Barbier]

Hi Matt,

Thanks this summary and for working on this!

Just a few comments/corrections about some specific points, hoping it
might help.

Matt  writes:

>   On Fri, 17 Nov 2023 10:20:28 +0100  Ihor Radchenko  wrote --- 
>
>  > This has nothing to do with Emacs comint and this is also not a bug in
>  > Emacs 
>
> Ihor, there were two claims made in the original report.  I was referring to 
> Claim 2.  That deals with M-x shell and therefore comint-mode.
>
> Regarding Claim 1:
>
> - Can anyone verify Claim 1?

I do: the file is created and the command "echo bar" is NOT executed.

Here is my code block and its results:

#+begin_src bash :results output
  ssh phone "echo foo>foo_file"
  echo "bar"
#+end_src

#+RESULTS:

No results (the echo command is NOT executed).

The file "foo_file" is created on the remote; its content is "foo".

#+begin_src bash :results output
  date
  ssh -n phone "ls -alh foo_file"
  ssh -n phone "cat foo_file"
#+end_src

#+RESULTS:
: Sat Nov 18 08:33:59 CET 2023
: -rw--- 1 u0_a256 u0_a256 4 Nov 18 08:26 foo_file
: foo



> - What versions are people using?
>   + M-x org-version
>   + M-x emacs-version

#+begin_src elisp
  (list emacs-version org-version)
#+end_src

#+RESULTS:
| 30.0.50 | 9.7-pre |

GNU/Linux gentoo

> ...

> * Comments about the claims:

> ** Comment 1.
> ...
> I am unable to reproduce the reported behavior (of
> "bar" not returning).  Instead, I get an ssh-askpass permission denied
> error, foo_file is not created, and "bar" is given as the result.  I
> do not see anywhere in the thread that the original claim was
> reproduced.

It seems your SSH failed to connect.  In that case, I cannot swallow the
second command; thus the command "echo bar" is executed.

I can reproduce what you see on my side if I force the connection to fail:

#+begin_src bash :results output
  ssh WRONG_REMOTE "echo foo>foo_file"
  echo "bar"
#+end_src

#+RESULTS:
: bar


>
> The thread preceded something like follows.
>
> Leo Butler suggested two work arounds:
>
> - add the -f to the ssh command


> - add a semi-colon and line continuation to the first line.
>
> Russell Adams suggested another work around:
>
> - add -n to the ssh command

That's the one I use; the option -n is enough for me ('-n' = Redirects
stdin from /dev/null). The option '-f' means SSH will go to background;
I'm not sure I want that.

> ...

> ... 
> He then proposes an experiment to close stdin.  To do this, he calls
>
> #+begin_src shell :results output
> exec 0>&-
> echo OK
> #+end_src
>
> He claims that "exec 0<&-" closes stdin.  I believe there is a typo.
> ...

You're right. Good catch, thanks!

Although it seems to work either way on my side.

#+begin_src shell :results output
  exec 0<&-
  echo OK
#+end_src

#+RESULTS:

#+begin_src shell :results output
  exec 0>&-
  echo OK
#+end_src

#+RESULTS:


> What Bruno writes corresponds to "closing output file descriptor 0".  I 
> honestly don't know what the difference is between an "output file 
> descriptor" and an "input file descriptor".  I had no luck finding this 
> information in man bash or info bash.
>

My point was: the commands are read the standard input, thus, any
command that modifies that standard input will modify what gets
executed.


> ...
> This is what we see in Org.  I'll be honest, though, I don't
> really know what to expect with exec 0>&- and exec 0<&-.  When I call
> them in the terminal, it kills the terminal.

Let's forget about 'exec 0<&-' (closing the standard input/outputs):
this is bringing other corner cases.  But, yes, I would expect a
terminal to close itself automatically if its input is closed.

> ...
> As far as I can tell, though, that's not what prevents "bar" from being 
> returned.  As far as I can reproduce, calling
>
> #+begin_src bash :results output
> ssh localhost "echo foo>foo_file"
> echo "bar"
> #+end_src
>
> *does* give "bar" for results even though it shouldn't.

Does it echo bar when the SSH connection succeeds too ?


Thanks again for working on this.


Bruno

Re: Forget about "bash -c bash file.sh" (Re: bash source code block: problem after ssh commands)

[Matt]

  On Sat, 18 Nov 2023 04:11:03 +0100  Max Nikulin  wrote --- 

 > >  bash -c bash /tmp/two-lines.sh
 > 
 >  From my point of view it was a plain mistake in attempts to simulate 
 > the issue outside of Emacs. There is no point to concentrate on this 
 > command. I tried to explain that it is incorrect usage of "-c" shell 
 > option and what is the actual effect of this call, but I seems I failed.

As an ob-shell user, my expectation is that execution within Org produces the 
same behavior as outside of Emacs.  This is why I've focused on the command.  
It acts as a guide for what is "correct."  Maybe this is misguided for a reason 
I don't yet see?

I concluded that the command is not "what Emacs does" and therefore isn't a 
valid source of "truth".  I agree it's not worth concentrating on it further.

Re: bash source code block: problem after ssh commands

[Max Nikulin]

On 25/10/2023 18:17, alain.coch...@unistra.fr wrote:

By contrast, it works with this one:

#+begin_src bash :results output
sshcoch...@fruc.u-strasbg.fr  "echo foo>foo_file" ; echo "bar"
#+end_src


What about

   #+begin_src bash :results output
   ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file" ; echo "bar"
   echo more
   #+end_src

?

Re: bash source code block: problem after ssh commands

[Max Nikulin]

On 17/11/2023 17:17, Ihor Radchenko wrote:

I was only able to reproduce your problem with ssh asking a password.
We are discussing the reproduced case.


I see bash vs. dash difference with public key authorization, so no need 
for password prompts. I have not figured out how to construct an example 
without ssh since this command *may* read stdin, but does not do it in a 
same way as e.g. cat(1). Perhaps a small program performing single 
non-blocking read will allow it. The following behavior observed for a 
regular shell prompt, Emacs is not involved. Debian 12 bookworm.


cat ssh-script.sh
ssh -p  127.0.0.1 'echo foo>/tmp/foo'
echo done

Read commands from a script file:

dash ssh-script.sh
done

bash ssh-script.sh
done

Read commands from stdin

dash 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


cat ssh-script.sh | strace -o /tmp/bash.strace bash

I am unsure if POSIX specifies exact behavior of shell when commands are 
read from stdin. I think, the suggested earlier "-n" ssh option (or 
stdin. There is too much room for heuristics: interactive vs. 
non-interactive shell, a terminal vs. a regular file vs. a pipe as 
standard input. Be explicit to get reliable behavior.


ssh -n user@host 'command'

or

tar cvf - . | ssh user@host 'tar xvf -'

without "-n" when ssh needs stdin and it is explicitly specified.

I do not think it is an Org or an Emacs bug. It is rather POSIX vs. bash 
vs. dash issue.