emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* 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

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).