Re: bash source code block: problem after ssh commands

Max Nikulin writes: >> May you submit a patch for the WORG docs that documents this caveat? > > 9733cc41 2024-07-03 17:57:15 +0700 ob-doc-shell.org: Warn concerning > optional stdin Thanks! -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at

Re: bash source code block: problem after ssh commands

On 01/07/2024 23:01, Ihor Radchenko wrote: Max Nikulin writes: bug#71081 is about shell-command-on-region, not about mailcap. (and pty may actually not matter there, because Windows' cmd.exe is not even POSIX-compient...) Of course, there are no pty's on Windows and cmd.exe is a special case.

Re: bash source code block: problem after ssh commands

Max Nikulin writes: >> I guess not on Windows (bug#71081). But otherwise I agree. > > It was for starting mailcap viewer and Windows was not an issue. bug#71081 is about shell-command-on-region, not about mailcap. (and pty may actually not matter there, because Windows' cmd.exe is not even POSIX

Re: bash source code block: problem after ssh commands

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

Re: bash source code block: problem after ssh commands

Max Nikulin writes: I do not see a great benefit of re-implementing session support via actual terminal. (I think we agree here). >>> >>> `shell' and so comint allocates "actual" pty. >> >> Are you sure? > ... > 123454 pts/0Sl 0:16 \_ emacs -Q > 125104 pts/4Ss+0:00

Re: bash source code block: problem after ssh commands

On 30/06/2024 23:42, Ihor Radchenko wrote: Max Nikulin writes: On 30/06/2024 22:28, Ihor Radchenko wrote: I do not see a great benefit of re-implementing session support via actual terminal. (I think we agree here). `shell' and so comint allocates "actual" pty. Are you sure? ps wf PI

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > On 30/06/2024 22:28, Ihor Radchenko wrote: >> I do not see a great benefit of re-implementing session support via >> actual terminal. (I think we agree here). > > `shell' and so comint allocates "actual" pty. Are you sure? -- Ihor Radchenko // yantar92, Org mode contribut

Re: bash source code block: problem after ssh commands

On 30/06/2024 22:28, Ihor Radchenko wrote: I do not see a great benefit of re-implementing session support via actual terminal. (I think we agree here). `shell' and so comint allocates "actual" pty. I expect that bracketed paste is just some escape sequences delimiting pasted text (fcntl calls

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > ... ob-shell might offer variants for sessions: dumb > stdin, source a temporary file, or bracketed paste. Anything besides > stdin (with its confusing differences from interactive sessions) is > almost certainly requires shell-specific code. And `shell' is likely not >

Re: bash source code block: problem after ssh commands

On 30/06/2024 18:06, Ihor Radchenko wrote: Max Nikulin writes: https://debbugs.gnu.org/67259 Notice that the report is for *interactive* sessions. Org babel sessions are not so interactive. They are to maintain state, not to interact with users directly... You are not right. We have legitima

Re: bash source code block: problem after ssh commands

Max Nikulin writes: > https://debbugs.gnu.org/67259 > > Notice that the report is for *interactive* sessions. Org babel sessions > are not so interactive. They are to maintain state, not to interact with > users directly... You are not right. We have legitimate cases when people can switch to

Re: bash source code block: problem after ssh commands

On 18/11/2023 22:51, Matt wrote: 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 beh

Re: bash source code block: problem after ssh commands

On 18/11/2023 15:04, Max Nikulin wrote: On 17/11/2023 17:17, Ihor Radchenko wrote: 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

Re: bash source code block: problem after ssh commands

On 22/11/2023 02:01, Bruno Barbier wrote: Ihor Radchenko writes: __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

Re: bash source code block: problem after ssh commands

Ihor Radchenko writes: > Bruno Barbier writes: > >> 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

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

Hi Max, Max Nikulin writes: > 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, >

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

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

Re: bash source code block: problem after ssh commands

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://my

Re: bash source code block: problem after ssh commands

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 hap

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

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 "f

Re: bash source code block: problem after ssh commands

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 exhauste

Re: bash source code block: problem after ssh commands

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

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

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 "ec

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

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

Re: bash source code block: problem after ssh commands

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 v

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

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 reaso

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

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,

Re: bash source code block: problem after ssh commands

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 ou

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

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.

Re: bash source code block: problem after ssh commands

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 b

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

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

Re: bash source code block: problem after ssh commands

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

Re: bash source code block: problem after ssh commands

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 exam

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

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

Re: bash source code block: problem after ssh commands

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.

Re: bash source code block: problem after ssh commands

Hi Matt, Ihor, Alain, Ihor Radchenko writes: > alain.coch...@unistra.fr writes: > >> At the most basic user level (i.e., non lisp aware), why is it not >> necessarily a bug if "something" does the expected in an X terminal >> but not in an emacs terminal? I think Matt and I (and others) are o

Re: bash source code block: problem after ssh commands

On Fri, Nov 17 2023, Ihor Radchenko wrote: > I was only able to reproduce your problem with ssh asking a password. > We are discussing the reproduced case. > > If you see problems with > >#+begin_src bash :results output >ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file" >echo "bar" >

Re: bash source code block: problem after ssh commands

alain.coch...@unistra.fr writes: > Ihor Radchenko writes on Fri 17 Nov 2023 09:22: > > > I think that I need to clarify here. > > Thank you. > > Well, thank you for _trying_: most of the discussion in this thread is > way beyond my pay grade. My reply was to Matthew, the current ob-shell maintai

Re: bash source code block: problem after ssh commands

Ihor Radchenko writes on Fri 17 Nov 2023 09:22: > I think that I need to clarify here. Thank you. Well, thank you for _trying_: most of the discussion in this thread is way beyond my pay grade. At the most basic user level (i.e., non lisp aware), why is it not necessarily a bug if "something"

Re: bash source code block: problem after ssh commands

Matt writes: > Thank you for clarifying. > > > Anyway, this gives me the opportunity to come back to the question of > > whether or not there is a problem with emacs itself (like some people > > here thought), and if some message should be sent to some emacs list. > > Again my argument was th

Re: bash source code block: problem after ssh commands

alaincochard alain.coch...@unistra.fr writes: > Yes. (So I think that explains the 'no' above.) Thank you for clarifying. > Anyway, this gives me the opportunity to come back to the question of > whether or not there is a problem with emacs itself (like some people > here thought), and if

Re: bash source code block: problem after ssh commands

Matt writes on Thu 16 Nov 2023 20:03: > > On Thu, 16 Nov 2023 10:30:59 +0100 Ihor Radchenko wrote --- > > > Or we can make use of TRAMP as we usually do to access remote > > environment. IMHO, it is more reliable as TRAMP takes care about > > arranging all the Elisp FS interacti

Re: bash source code block: problem after ssh commands

On Thu, 16 Nov 2023 10:30:59 +0100 Ihor Radchenko wrote --- > Or we can make use of TRAMP as we usually do to access remote > environment. IMHO, it is more reliable as TRAMP takes care about > arranging all the Elisp FS interaction to work on remote system. Agreed. Also, I wasn't

Re: bash source code block: problem after ssh commands

Matt writes: > So, rather than start a comint and then ssh from there, it's possible to let > Emacs start the subprocess, manage the ssh connection, and just read that. > Emacs makes a buffer from a network stream by calling start-process` using > `shell-file-name`. `org-babel-shell-initiali

Re: bash source code block: problem after ssh commands

On Wed, 15 Nov 2023 17:32:19 +0100 Matt wrote --- > (let ((buff "*localhost-process-buffer*")) > (switch-to-buffer >(make-comint-in-buffer > "localhost-process" > buff > "ssh" > nil > (format "%s@localhost" (getenv "USER") It looks like the way thi

Re: bash source code block: problem after ssh commands

I was poking around, learning how sessions are started. Basically, `shell` creates the comint buffer using `make-comint-in-buffer`. What I find interesting is that `make-comint-in-buffer` can also create a comint buffer from a network stream: (let ((buff "*localhost-process-buffer*")) (sw

Re: bash source code block: problem after ssh commands

On Thu, 09 Nov 2023 13:13:36 +0100 Ihor Radchenko wrote --- > A bigger problem is that errors *Org Babel Error > Output* are not clickable: Interesting. > So, it looks like we may need an alternative `org-babel-eval' function > that works with script files rather than input and a

Re: bash source code block: problem after ssh commands

Matt writes: > ... Aside from permission, any code we > insert needs to be correct. For example, a shebang would need to point > to the correct application and any arguments would need to correspond > to the implementation being called. I doubt we'd need anything beyond > /bin/. FWIW, it looks li

Re: bash source code block: problem after ssh commands

On Tue, 07 Nov 2023 09:53:46 +0100 Ihor Radchenko wrote --- > Matt m...@excalamus.com> writes: > > > On Mon, 06 Nov 2023 14:32:16 +0100 Ihor Radchenko wrote --- > > > I am wondering about the possible downsides of using script approach > > > instead of stdin redirection.

Re: bash source code block: problem after ssh commands

Matt writes: > On Mon, 06 Nov 2023 14:32:16 +0100 Ihor Radchenko wrote --- > > I am wondering about the possible downsides of using script approach > > instead of stdin redirection. > > I'm curious to hear more about what you're thinking. I am thinking to change the (t (org-babel-

Re: bash source code block: problem after ssh commands

Matt writes on Mon 6 Nov 2023 19:01: > I want to confirm, are you able to accomplish your task by using > '-n'? Yes. Evaluating this block (with C-c C-c): #+begin_src bash :results output ssh -n coch...@fruc.u-strasbg.fr "echo foo>foo_file" echo "bar" #+end_src gives #+RESUL

Re: bash source code block: problem after ssh commands

On Mon, 06 Nov 2023 14:32:16 +0100 Ihor Radchenko wrote --- > I am wondering about the possible downsides of using script approach > instead of stdin redirection. I'm curious to hear more about what you're thinking.

Re: bash source code block: problem after ssh commands

On Fri, 27 Oct 2023 13:47:24 +0200 alain.coch...@unistra.fr wrote --- > Russell Adams writes on Thu 26 Oct 2023 16:44: > > [...] are you using an SSH key to connect, or entering a password? > > If you use an SSH key for passwordless access, try adding -n (ie: > > > "ssh -n derp@h

Re: bash source code block: problem after ssh commands

Bruno Barbier writes: > 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. Looking

Re: bash source code block: problem after ssh commands

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

Re: bash source code block: problem after ssh commands

On 28/10/2023 01:26, alain.coch...@unistra.fr wrote: bash -c "bash /path/to/file-containing-the-source-code.sh" Without the quotes, the 1st line is not executed either. NB: I get the same behavior with simply Without quotes it means: execute shell script (just "bash" this case) with "$0"

Re: bash source code block: problem after ssh commands

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

Re: bash source code block: problem after ssh commands

Russell Adams writes on Thu 26 Oct 2023 16:44: > [...] are you using an SSH key to connect, or entering a password? > If you use an SSH key for passwordless access, try adding -n (ie: > "ssh -n derp@host mycommand"). Yes, I use an SSH key, and yes, '-n' saves the day. Thanks. -- EOST (Éco

Re: bash source code block: problem after ssh commands

On Wed, Oct 25, 2023 at 01:17:42PM +0200, alain.coch...@unistra.fr wrote: >#+begin_src bash :results output >ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file" >echo "bar" >#+end_src I know that Ihor has already reproduced, but are you using an SSH key to connect, or entering a pass

Re: bash source code block: problem after ssh commands

alain.coch...@unistra.fr writes: > Ihor Radchenko writes on Thu 26 Oct 2023 08:44: > > > I currently do not have a setup to test ssh commands, > > Sorry if that's irrelevant: I realized that one can ssh to the *same* > machine. You are indeed right. I can now reproduce the problem locally. It b

Re: bash source code block: problem after ssh commands

Ihor Radchenko writes on Thu 26 Oct 2023 08:44: > I currently do not have a setup to test ssh commands, Sorry if that's irrelevant: I realized that one can ssh to the *same* machine.

Re: bash source code block: problem after ssh commands

Leo Butler writes: > It looks like an issue in comint-mode and the way that it is handling > the temporary ssh session. This is not an issue with org-mode. > ... > Not working: > > #+begin_src bash :results output > ssh SSH-HOST 'echo foo>/tmp/foo_file' > echo $(uname -a) |tee /tmp/uname1.txt

Re: bash source code block: problem after ssh commands

So it is an issue with emacs, right? comint-mode -- (yaxp me) => t

Re: bash source code block: problem after ssh commands

On Wed, Oct 25 2023, alain.coch...@unistra.fr wrote: > Thanks much for the detailed explanations. > > > It looks like an issue in comint-mode and the way that it is > > handling the temporary ssh session. This is not an issue with > > org-mode. > > So it is an issue with emacs, right? Yes, tha

Re: bash source code block: problem after ssh commands

Thanks much for the detailed explanations. > It looks like an issue in comint-mode and the way that it is > handling the temporary ssh session. This is not an issue with > org-mode. So it is an issue with emacs, right? -- EOST (École et Observatoire des Sciences de la Terre) ITE (Institut

Re: bash source code block: problem after ssh commands

On Wed, Oct 25 2023, alain.coch...@unistra.fr wrote: > Hello. > > For me, 'C-c C-c' on the following group > >#+begin_src bash :results output >echo "foo" >echo "bar" >#+end_src > > > works as I expect: 'foo' and 'bar' are echo'ed. But it fails on this > one: > >#+begin_src ba