Re: Shouldn't ob-shell's org-babel-expand-src-block prepend the :shebang value?

[Tom Gillespie]

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
>