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

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

[Max Nikulin]

On 18/11/2023 05:07, Matt wrote:

Consider calling

 bash -c bash /tmp/two-lines.sh


Matt, could you, please, describe what this command should do 
accordingly to your expectations?


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.


Hints:
- Try this command in a regular shell prompt outside of Emacs
- Try "echo $$" before and after this command
- Try it with a script having a clear side effect and check whether it 
is produced, e.g. "date >>/tmp/touch-tmp-file.txt"