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
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
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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.
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
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
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
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
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
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.
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
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"
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
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"
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
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
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
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
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`.
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
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*"))
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
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
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
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
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
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.
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
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
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
> >
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
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)
>
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
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
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
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.
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
So it is an issue with emacs, right?
comint-mode
--
(yaxp me) => t
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,
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
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
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 bash :results output
ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
54 matches
Mail list logo
