Re: problem in sorting headings that start with timestamps

Uwe Brauer writes: >> You can sort alphabetically. But timestamp is considered a part of the >> headline. >> If you need something custom, provide custom key/comparison function for >> `org-sort-entries'. > > So you mean I should write a new sort function myself and use advice to > «connect» it

Re: problem in sorting headings that start with timestamps

> Uwe Brauer via "General discussions about Org-mode." > writes: > You can sort alphabetically. But timestamp is considered a part of the > headline. > If you need something custom, provide custom key/comparison function for > `org-sort-entries'. So you mean I should write a new sort function

Re: problem in sorting headings that start with timestamps

Uwe Brauer via "General discussions about Org-mode." writes: > I am not sure this is a feature or a bug. > Consider the following > > --8<---cut here---start->8--- > * Test 1 > ** <2025-02-08 09:46> First > ** <2025-02-08 09:51> All > --8<---cut h

[BUG] Imenu, problem at first pass [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

n the expected way on that file. + Any org-file I tested showed the same problem. Here is a simple one: * One ** One a * Two * Three * Four Emacs : GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43,

problem in sorting headings that start with timestamps

Hi I am not sure this is a feature or a bug. Consider the following --8<---cut here---start->8--- * Test 1 ** <2025-02-08 09:46> First ** <2025-02-08 09:51> All --8<---cut here---end--->8--- If I run `org-sort` the head

Re: Problem installing Org using the Emacs packaging system

Ihor Radchenko writes: > I think that we should: > 1. Remove this from Org 9.7 manual (bugfix) > 2. Add a note that the one-liner requires Emacs 30 in the Org 9.8-re >manual (main) Fixed, on main, and on bugfix. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9f5fce73e9 https

Re: Problem installing Org using the Emacs packaging system

Ihor Radchenko writes on Sun 22 Dec 2024 09:19: > May you please elaborate what you mean? The command from the manual is > indeed not working in Emacs 29. It just was a bit funny to me when you said "Maybe forgot to test on older Emacs", considering that 29.4 is the last version that one can d

Re: Problem installing Org using the Emacs packaging system

alain.coch...@unistra.fr writes: > > I suspect that it is some kind of bug in Emacs 29. It seems that the > > command is only properly working in Emacs 30. > ... > Thanks a lot for the feedback. I hope Emacs 29 (the current official > version, right?) is not too old already :-) May you please

Re: Problem installing Org using the Emacs packaging system

Ihor Radchenko writes on Mon 16 Dec 2024 19:08: > I suspect that it is some kind of bug in Emacs 29. It seems that the > command is only properly working in Emacs 30. > > I am not sure how I overlooked the problem. Maybe forgot to test things > on older Emacs somehow. >

Re: Problem installing Org using the Emacs packaging system

alain.coch...@unistra.fr writes: > Hello. About 2 weeks ago I already sent the following message. I just > realized that I must have failed in removing all the 'In-Reply-To:' and > similar fields, so it is part of another thread. I was thinking this might > be the reason why it was ignored and

Re: Problem installing Org using the Emacs packaging system

;org))" > > I have used the emacs batch command above on a number of machines but it > always failed (see below), so I guess I am doing something wrong, but what? I suspect that it is some kind of bug in Emacs 29. It seems that the command is only properly working in Emacs 30. I am n

Problem installing Org using the Emacs packaging system

Hello. About 2 weeks ago I already sent the following message. I just realized that I must have failed in removing all the 'In-Reply-To:' and similar fields, so it is part of another thread. I was thinking this might be the reason why it was ignored and I dare submit it again. I apologize for

Problem installing Org using the Emacs packaging system

Hello. An excerpt of the page https://orgmode.org/manual/Installation.html is Using Emacs packaging system Recent Emacs distributions include a packaging system which lets you install Elisp libraries. You can install Org from the “package menu”, with M-x list-packages. See Packag

Re: Org v9.7.7 org-assert-version problem?

David Masterson writes: > I just tried to package-install org-9.7.7 and I'm getting a problem with > org-assert-version. It looks like a conflict between the system > installed version of 9.5.5 and my ~/.emacs.d/elpa install of 9.7.7. The > main problem (so far) seems to be o

Org v9.7.7 org-assert-version problem?

I just tried to package-install org-9.7.7 and I'm getting a problem with org-assert-version. It looks like a conflict between the system installed version of 9.5.5 and my ~/.emacs.d/elpa install of 9.7.7. The main problem (so far) seems to be org-assert-version -- even Hyperbole seems

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: strange export problem with a file: link

On Saturday, 20 Apr 2024 at 12:25, Ihor Radchenko wrote: > Fixed, on main. Thank you! -- : Eric S Fraga, with org release_9.6.23-1320-g1be2f9 in Emacs 30.0.50

Re: strange export problem with a file: link

"Fraga, Eric" writes: > I have a file that consists of these three lines: > > --8<---cut here---start->8--- > #+begin_src latex :results file raw :exports results :file function.png > \[ y = f(x) \] > #+end_src > --8<---cut here---end---

Re: strange export problem with a file: link

On Thursday, 18 Apr 2024 at 21:46, Max Nikulin wrote: > Sorry that I was not clear enough. Org code should be fixed. For a > while you may revert that commit in your local repository. Ah, okay! Thank you. I'll leave my documents as they are then. :-) -- : Eric S Fraga, with org release_9.6.23-

Re: strange export problem with a file: link

On 18/04/2024 21:37, Fraga, Eric wrote: On Thursday, 18 Apr 2024 at 19:08, Max Nikulin wrote: It is a side effect of 72b0e9ff0 2024-02-05 16:39:05 +0100 Ihor Radchenko: org-export: Do not strip link type by default during export I have now checked the ORG-NEWS file, which I probably should ha

Re: strange export problem with a file: link

moved to using MathML instead for what I need doing right now so the problem is no longer an issue for me (at the moment). However, although I'm sure there was a good reason for the change, it has broken quite a few of my documents! Not complaining; just noting. Living at the edge does carry a p

Re: strange export problem with a file: link

On 18/04/2024 17:50, Fraga, Eric wrote: #+begin_src latex :results file raw :exports results :file function.png \[ y = f(x) \] #+end_src org-odt-export-to-odt: OpenDocument export failed: Opening input file: No such file or directory, /tmp/file:function.png It is a side effect of 72b0e9ff0 2

strange export problem with a file: link

Hello all, I have a file that consists of these three lines: --8<---cut here---start->8--- #+begin_src latex :results file raw :exports results :file function.png \[ y = f(x) \] #+end_src --8<---cut here---end--->8--- With "

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

Uwe Brauer via "General discussions about Org-mode." writes: > Ok understood, but then, who can I add hlines to table that does not > possess any? #+name: test | 1 | 2 | | 3 | 4 | #+name: add-hlines #+begin_src emacs-lisp :var table='(1 2) :results value (let (result) (when table (unless

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

>>> "IR" == Ihor Radchenko writes: > Uwe Brauer via "General discussions about Org-mode." > writes: >> #+NAME: many-cols >> | a | b | c | >> | d | e | f | >> | g | h | i | >> >> #+NAME: hline-please >> #+BEGIN_SRC python :var tab=many-cols :hlines yes >> return tab >> #+END_SRC >> >> #+RESULT

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

Uwe Brauer via "General discussions about Org-mode." writes: > #+NAME: many-cols > | a | b | c | > | d | e | f | > | g | h | i | > > #+NAME: hline-please > #+BEGIN_SRC python :var tab=many-cols :hlines yes > return tab > #+END_SRC > > #+RESULTS: hline-please > | a | b | c | > | d | e | f | > | g

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

> Uwe Brauer via "General discussions about Org-mode." > writes: > No, this is because you customized `org-src-preserve-indentation' or > `org-edit-src-content-indentation', while the provided example only > works with default indentation settings. Python is sensitive to > whitespace and your c

Re: problem with https://orgmode.org/manual/Results-of-Evaluation.html

Uwe Brauer via "General discussions about Org-mode." writes: > I tried to use the examples of the above link > ... > #+NAME: no-hline > #+BEGIN_SRC python :var tab=many-cols :hlines no > return tab > #+END_SRC > > Now already the first failed: > , > | > | File "", line 4 > | return t

problem with https://orgmode.org/manual/Results-of-Evaluation.html

t;, line 4 | return tab | ^ | IndentationError: unexpected indent | [ Babel evaluation exited with code 1 ] `---- Problem could be that which python on my Ubuntu system returns Python 2.7.12 I presume the code is for python 3.X. How can I tell org to use that one? Regards Uwe Brauer --

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

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

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

think Matt and I (and others) are on >> the same page here, and he already essentially drafted the bug report >> I would have sent (only better). > > 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 origi

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 fo

Re: bash source code block: problem after ssh commands

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). > What also confuses me is that it seems to me that, in the minimum > working example, you conside

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. &g

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 >

Re: bash source code block: problem after ssh commands

echo "bar" > #+end_src > > Clearly, the ssh line is intended to happen on the remote server. > Was the echo "bar" intended to happen locally? Yes. (So I think that explains the 'no' above.) Then I'm confused about your confusion... Anyway, this

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 rath

Re: bash source code block: problem after ssh commands

bin/. FWIW, it looks like there's been at least one instance > where :shebang's formatting was questioned > (https://yhetil.org/orgmode/ca+a2izz1vmmkiuf4fem1au7ca1m9gqap+bkvrosz+0bxrt6...@mail.gmail.com/). It is a problem, but I am not sure how useful it is to solve the line numbe

Re: bash source code block: problem after ssh commands

> instead of stdin redirection. > > > > I'm curious to hear more about what you're thinking. > > I am thinking to change the > (t (org-babel-eval shell-file-name (org-trim body))) > clause in `org-babel-sh-evaluate' to something that uses a scri

Re: bash source code block: problem after ssh commands

g to change the (t (org-babel-eval shell-file-name (org-trim body))) clause in `org-babel-sh-evaluate' to something that uses a script file. It will clearly solve the discussed problem, possibly at the cost of small overhead to write the script file to disk. -- Ihor Radchenko // yantar

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

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 >

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 reproduc

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

bash source code block: problem after ssh commands

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

Re: [BUG] HTML export locale problem [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

em...@supporter.mailer.me writes: > Today I was exporting my org file to HTML and I have run into an issue > with #+LANGUAGE. > I have set it to to "pl" and the Table of Contents name has changed, but > the figure names did not. > > Can somebody guide me on how could I fix it? This is

[BUG] HTML export locale problem [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

Hello everyone, Today I was exporting my org file to HTML and I have run into an issue with #+LANGUAGE. I have set it to to "pl" and the Table of Contents name has changed, but the figure names did not. Can somebody guide me on how could I fix it? Kind regards Emacs User Info:

Re: problem with org-map-entries and the doc for export hooks

Le 08 Jun 2023, Ihor Radchenko a écrit : > "Victor A. Stoichita" writes: > >> I still see the problem with org version 9.6.6 and your latest example >> code. >> >> I also checked with emacs -Q which has org version 9.6.1. >> >> I’m testing

Re: problem with org-map-entries and the doc for export hooks

"Victor A. Stoichita" writes: > I still see the problem with org version 9.6.6 and your latest example > code. > > I also checked with emacs -Q which has org version 9.6.1. > > I’m testing this on the attached file. Thanks for providing an example! You encount

Re: problem with org-map-entries and the doc for export hooks

t.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=16f15f966 Thanks for the hints Ihor ! I still see the problem with org version 9.6.6 and your latest example code. I also checked with emacs -Q which has org version 9.6.1. I’m testing this on the attached file. I also see that if I set t

  1   2   3   4   5   6   7   8   9   10   >