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

• • [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 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).