* Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? @ 2020-03-13 1:03 Vladimir Nikishkin 2020-09-05 5:00 ` Bastien 0 siblings, 1 reply; 6+ messages in thread From: Vladimir Nikishkin @ 2020-03-13 1:03 UTC (permalink / raw) To: emacs-orgmode I use C-c C-v C-v quite often to check the final file produced. I use ob-shell with the :shebang of "#!/usr/bin/chibi-scheme", because my code is actually scheme-script, and I need to use :stdin, which isn't supported by ob-scheme and geiser. (And geiser also has some not inconveniences). However, when I expand the block, the shebang line is not added to the top. The top line could also be potentially used for file type detection, and what is also annoying, errors reported by the interpreter are off by 1 (due to the missing first line). -- Yours sincerely, Vladimir Nikishkin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? 2020-03-13 1:03 Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? Vladimir Nikishkin @ 2020-09-05 5:00 ` Bastien [not found] ` <CA+A2iZbJrNC3Rx5oAvyamBM_BObP8bxyTiFKtzxDrJhqe1MKsQ@mail.gmail.com> 0 siblings, 1 reply; 6+ messages in thread From: Bastien @ 2020-09-05 5:00 UTC (permalink / raw) To: Vladimir Nikishkin; +Cc: emacs-orgmode Hi Vladimir, Vladimir Nikishkin <lockywolf@gmail.com> writes: > I use C-c C-v C-v quite often to check the final file produced. > I use ob-shell with the :shebang of "#!/usr/bin/chibi-scheme", because > my code is actually scheme-script, and I need to use :stdin, which > isn't supported by ob-scheme and geiser. (And geiser also has some not > inconveniences). > > However, when I expand the block, the shebang line is not added to the > top. The top line could also be potentially used for file type > detection, and what is also annoying, errors reported by the > interpreter are off by 1 (due to the missing first line). can you share your suggestion as a patch? It will be easier to read it and evaluate its relevance. If you need directions on how to share a patch, let us know. Thanks! -- Bastien ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CA+A2iZbJrNC3Rx5oAvyamBM_BObP8bxyTiFKtzxDrJhqe1MKsQ@mail.gmail.com>]
[parent not found: <87d030ae7g.fsf@bzg.fr>]
* Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? [not found] ` <87d030ae7g.fsf@bzg.fr> @ 2020-09-10 6:52 ` Vladimir Nikishkin 2020-09-10 7:10 ` Tom Gillespie 2020-09-10 7:30 ` Tim Cross 0 siblings, 2 replies; 6+ messages in thread From: Vladimir Nikishkin @ 2020-09-10 6:52 UTC (permalink / raw) To: Bastien, emacs-orgmode So, my point is the following. A shebang is an almost universally accepted way to specify which interpreter should be used for code evaluation. In the ob-core.el, at line 787, the function called org-babel-expand-src-block makes a buffer out of the noweb-expanded code. (I am working with org 20200907) The sexp is looking like this: (org-edit-src-code expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*")) I suggest replacing this sexp with (org-edit-src-code (seq-concatenate 'string (or (alist-get :shebang params) "") "\n" expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*")) This way the expanded buffer would respect the shebang, and the resulting buffer would be saveable as a runnable file. I suspect that the second branch of the (if) should be left as it is, because non-interactive usage probably means that the code will be used later as a part of something, and therefore does not need a shebang. Vlad On Sat, 5 Sep 2020 at 15:13, Bastien <bzg@gnu.org> wrote: > > Vladimir Nikishkin <lockywolf@gmail.com> writes: > > > I'll try to do one this week, but I can't submit a patch officially > > because of my employer being staunchly against signing the copyright > > disclaimer. > > :/ > > So please just give directions on what to modify and how, and that'd > be enough for someone (probably me) to get started. > > Thanks! > > -- > Bastien -- Yours sincerely, Vladimir Nikishkin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? 2020-09-10 6:52 ` Vladimir Nikishkin @ 2020-09-10 7:10 ` Tom Gillespie 2020-09-10 7:29 ` Vladimir Nikishkin 2020-09-10 7:30 ` Tim Cross 1 sibling, 1 reply; 6+ messages in thread From: Tom Gillespie @ 2020-09-10 7:10 UTC (permalink / raw) To: Vladimir Nikishkin; +Cc: Bastien, emacs-orgmode Hi Vladimir, I have encountered similar issues with wanting to have a racket #lang line included in a tangled block while also allowing org to know exactly which #lang it is working with. I haven't found a good solution. One issue with embedding the shebang when editing a buffer is that it is very likely to cause confusion because the shebang line will not actually be included when executing the code, or if it was included then there is a reasonable possibility that in some cases it would not be included as the first line due to the addition of a prologue section. It also becomes necessary to remove the shebang line from the edit buffer, which means you have to know which shebang lines were added automatically and which were not. Further, the need to keep what will be run by org babel in line with what is shown via these various views makes it seem unlikely that this should be implemented as default behavior. I have a long email that touches on these issues in the works for after the 9.4 release, so thank you for providing an excellent example. It seems like one possible solution for your workflow would be to advise org-babel-expand-src-block to insert the shebang. Best, Tom On Wed, Sep 9, 2020 at 11:53 PM Vladimir Nikishkin <lockywolf@gmail.com> wrote: > > So, my point is the following. A shebang is an almost universally > accepted way to specify which interpreter should be used for code > evaluation. > > In the ob-core.el, at line 787, the function called > org-babel-expand-src-block makes a buffer out of the noweb-expanded > code. > (I am working with org 20200907) > > The sexp is looking like this: > > (org-edit-src-code > expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*")) > > I suggest replacing this sexp with > > (org-edit-src-code > (seq-concatenate 'string (or (alist-get :shebang params) "") "\n" > expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang " > ]*")) > > This way the expanded buffer would respect the shebang, and the > resulting buffer would be saveable as a runnable file. > > I suspect that the second branch of the (if) should be left as it is, > because non-interactive usage probably means that the code will be > used later as a part of something, and therefore does not need a > shebang. > > Vlad > > On Sat, 5 Sep 2020 at 15:13, Bastien <bzg@gnu.org> wrote: > > > > Vladimir Nikishkin <lockywolf@gmail.com> writes: > > > > > I'll try to do one this week, but I can't submit a patch officially > > > because of my employer being staunchly against signing the copyright > > > disclaimer. > > > > :/ > > > > So please just give directions on what to modify and how, and that'd > > be enough for someone (probably me) to get started. > > > > Thanks! > > > > -- > > Bastien > > > > -- > Yours sincerely, Vladimir Nikishkin > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? 2020-09-10 7:10 ` Tom Gillespie @ 2020-09-10 7:29 ` Vladimir Nikishkin 0 siblings, 0 replies; 6+ messages in thread From: Vladimir Nikishkin @ 2020-09-10 7:29 UTC (permalink / raw) To: Tom Gillespie; +Cc: Bastien, emacs-orgmode Well, why exactly Racket people decided to introduce the #lang directive in such a way that it looks like a shell comment or a shebang line seems to elude my understanding. (declare :lang 'whatever), at least to me, seems much more lispy, and even (read) able by a standard reader (which could later be switched to a different mode). >because the shebang line will not actually be included when executing the code How so? I never had problems using shebangs in my code. They seem to be prepended to the autogenerated files in /tmp/org-* just fine (in some other function). >due to the addition of a prologue section When does this happen? :prologue seems to be already included in the 'expanded variable. >It also becomes necessary to remove the shebang line from the edit buffer C-c C-v C-v does not make an edit buffer. It expands the buffer for a preview. I never suggested to prepend a shebang to the C-' buffer. In fact, saving the C-c C-v C-v buffer is the only reasonable thing you can do to it. Editing it makes no direct sense, because expansion is a many-to-one process, and you cannot "unexpand" the buffer (without evil diff trickery at least). >the need to keep what will be run by org babel in line This actually _is_ about keeping the two things in line. When evaluating a noweb-enabled block, and in fact, any block, org already prepends the :shebang value. I'm just suggesting to make the preview consistent On Thu, 10 Sep 2020 at 15:11, Tom Gillespie <tgbugs@gmail.com> wrote: > > Hi Vladimir, > I have encountered similar issues with wanting to have a racket > #lang line included in a tangled block while also allowing org to know > exactly which #lang it is working with. I haven't found a good > solution. One issue with embedding the shebang when editing a buffer > is that it is very likely to cause confusion because the shebang line > will not actually be included when executing the code, or if it was > included then there is a reasonable possibility that in some cases it > would not be included as the first line due to the addition of a > prologue section. It also becomes necessary to remove the shebang line > from the edit buffer, which means you have to know which shebang lines > were added automatically and which were not. Further, the need to keep > what will be run by org babel in line with what is shown via these > various views makes it seem unlikely that this should be implemented > as default behavior. I have a long email that touches on these issues > in the works for after the 9.4 release, so thank you for providing an > excellent example. It seems like one possible solution for your > workflow would be to advise org-babel-expand-src-block to insert the > shebang. Best, > Tom > > On Wed, Sep 9, 2020 at 11:53 PM Vladimir Nikishkin <lockywolf@gmail.com> wrote: > > > > So, my point is the following. A shebang is an almost universally > > accepted way to specify which interpreter should be used for code > > evaluation. > > > > In the ob-core.el, at line 787, the function called > > org-babel-expand-src-block makes a buffer out of the noweb-expanded > > code. > > (I am working with org 20200907) > > > > The sexp is looking like this: > > > > (org-edit-src-code > > expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*")) > > > > I suggest replacing this sexp with > > > > (org-edit-src-code > > (seq-concatenate 'string (or (alist-get :shebang params) "") "\n" > > expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang " > > ]*")) > > > > This way the expanded buffer would respect the shebang, and the > > resulting buffer would be saveable as a runnable file. > > > > I suspect that the second branch of the (if) should be left as it is, > > because non-interactive usage probably means that the code will be > > used later as a part of something, and therefore does not need a > > shebang. > > > > Vlad > > > > On Sat, 5 Sep 2020 at 15:13, Bastien <bzg@gnu.org> wrote: > > > > > > Vladimir Nikishkin <lockywolf@gmail.com> writes: > > > > > > > I'll try to do one this week, but I can't submit a patch officially > > > > because of my employer being staunchly against signing the copyright > > > > disclaimer. > > > > > > :/ > > > > > > So please just give directions on what to modify and how, and that'd > > > be enough for someone (probably me) to get started. > > > > > > Thanks! > > > > > > -- > > > Bastien > > > > > > > > -- > > Yours sincerely, Vladimir Nikishkin > > -- Yours sincerely, Vladimir Nikishkin ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? 2020-09-10 6:52 ` Vladimir Nikishkin 2020-09-10 7:10 ` Tom Gillespie @ 2020-09-10 7:30 ` Tim Cross 1 sibling, 0 replies; 6+ messages in thread From: Tim Cross @ 2020-09-10 7:30 UTC (permalink / raw) To: emacs-orgmode Vladimir Nikishkin <lockywolf@gmail.com> writes: > So, my point is the following. A shebang is an almost universally > accepted way to specify which interpreter should be used for code > evaluation. > > In the ob-core.el, at line 787, the function called > org-babel-expand-src-block makes a buffer out of the noweb-expanded > code. > (I am working with org 20200907) > > The sexp is looking like this: > > (org-edit-src-code > expanded (concat "*Org-Babel Preview " (buffer-name) "[ " lang " ]*")) > > I suggest replacing this sexp with > > (org-edit-src-code > (seq-concatenate 'string (or (alist-get :shebang params) "") "\n" > expanded) (concat "*Org-Babel Preview " (buffer-name) "[ " lang " > ]*")) > > This way the expanded buffer would respect the shebang, and the > resulting buffer would be saveable as a runnable file. > > I suspect that the second branch of the (if) should be left as it is, > because non-interactive usage probably means that the code will be > used later as a part of something, and therefore does not need a > shebang. > > Vlad > I'm not sure about this one. - I often have multiple src blocks which make up one final script once tangled. When editing these blocks, I don't want a shebang line for each of them. - Would this work with different shells? I write scripts in multiple shell dialects e.g. bash, sh, zsh, ksh etc. Will this add the correct shebang? - Which form of shebang e.g #!/bin/<shell> or #!/usr/bin/env <shell>? The only thing worse than having to add the shebang manually is having to remember to remove/change it when not needed :) Perhaps this could be a user configurable option that you can turn on if you want it rather than a default action? -- Tim Cross ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-09-10 7:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-03-13 1:03 Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value? Vladimir Nikishkin 2020-09-05 5:00 ` Bastien [not found] ` <CA+A2iZbJrNC3Rx5oAvyamBM_BObP8bxyTiFKtzxDrJhqe1MKsQ@mail.gmail.com> [not found] ` <87d030ae7g.fsf@bzg.fr> 2020-09-10 6:52 ` Vladimir Nikishkin 2020-09-10 7:10 ` Tom Gillespie 2020-09-10 7:29 ` Vladimir Nikishkin 2020-09-10 7:30 ` Tim Cross
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.