From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Derek Feichtinger <derek.feichtinger@psi.ch>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bug: org-babel-expand-src-block expands sh blocks independent of shell defined by src block [9.0.5 (9.0.5-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20170210/)]
Date: Mon, 08 May 2017 11:54:46 +0200 [thread overview]
Message-ID: <87shkf65cp.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <9837c90a-ff74-443d-e585-2a4c240dd52a@psi.ch> (Derek Feichtinger's message of "Sun, 7 May 2017 17:47:05 +0200")
Hello,
Derek Feichtinger <derek.feichtinger@psi.ch> writes:
> When using =org-babel-expand-src-block= with a shell src block one
> always gets the same code expansion (in my case bash) independent of the
> shell that is used while the execution of the shell block uses the
> correct expansion.
>
>
> I define the following table to illustrate the problem:
>
> #+NAME: tbltest
> | col1 | col2 | col3 |
>
> | 11 | 12 | 13 |
> | 21 | 22 | 23 |
> | 31 | 32 | 33 |
>
> Now for the example source block where I read in the table
>
> #+BEGIN_SRC sh :results value :exports both :var tbl=tbltest :colnames yes
> echo $tbl
> #+END_SRC
>
>
> When expanding the sh source block above with
> =org-babel-expand-src-block= it is wrongly expanded to the
> bash expansion and not to the sh expansion that is used when the block
> is executed. So, instead of the
> sh expansion,
>
> tbl='11 12 13
> 21 22 23
> 31 32 33'
>
>
> I see the following bash related expansion in the opened buffer:
>
> #+BEGIN_EXAMPLE
> unset tbl
> declare -A tbl
> tbl['11']='12
> 13'
> tbl['21']='22
> 23'
> tbl['31']='32
> 33'
> echo $tbl
> #+END_EXAMPLE
>
>
> Reason:
>
> The case distinction in =org-babel-variable-assignments:shell= is
> made based on the shell-file-name which is a standard emacs
> variable set by emacs in C code. This is pointing to "/bin/bash"
> for my installation.
>
> #+BEGIN_SRC elisp :exports source
> (defun org-babel-variable-assignments:shell (params)
> "Return list of shell statements assigning the block's variables."
> (let ((sep (cdr (assq :separator params)))
> (hline (when (string= "yes" (cdr (assq :hlines params)))
> (or (cdr (assq :hline-string params))
> "hline"))))
> (mapcar
> (lambda (pair)
> (if (string-suffix-p "bash" shell-file-name)
> (org-babel--variable-assignments:bash
> (car pair) (cdr pair) sep hline)
> (org-babel--variable-assignments:sh-generic
> (car pair) (cdr pair) sep hline)))
> (org-babel--get-vars params))))
> #+END_SRC
>
>
> Looking at the calls stack for the case where we execute the source
> block and where we just expand it, we see
> the following call stack for execution
>
> #+BEGIN_EXAMPLE
> org-babel-variable-assignments:shell
> org-babel-execute:shell
> org-babel-execute:sh
> org-babel-execute-src-block
> #+END_EXAMPLE
>
>
> while in the case of just expanding the source block we have
>
> #+BEGIN_EXAMPLE
> org-babel-variable-assignments:sh
> org-babel-expand-src-block
> #+END_EXAMPLE
>
>
> Note that =org-babel-variable-assignments:sh= is an alias for
> =org-babel-variable-assignments:shell=.
>
> A bit of investigation shows that for all shell languages there
> are aliases defined that finally call
> =org-babel-execute:shell=. This is set up in the
> =org-babel-shell-initialize= function. And it is set up in a way
> that =shell-file-name= is overridden by the name of the
> particular shell, and this then leads to the correct case
> distinction using =shell-file-name= in
> =org-babel-variable-assignments:shell=.
>
> #+BEGIN_SRC elisp :exports source
> (defun org-babel-shell-initialize ()
> "Define execution functions associated to shell names.
> This function has to be called whenever `org-babel-shell-names'
> is modified outside the Customize interface."
> (interactive)
> (dolist (name org-babel-shell-names)
> (eval `(defun ,(intern (concat "org-babel-execute:" name))
> (body params)
> ,(format "Execute a block of %s commands with Babel." name)
> (let ((shell-file-name ,name))
> (org-babel-execute:shell body params))))
> (eval `(defalias ',(intern (concat
> "org-babel-variable-assignments:" name))
> 'org-babel-variable-assignments:shell
> ,(format "Return list of %s statements assigning to the block's \
> variables."
> name)))))
> #+END_SRC
>
> The same kind of overriding would have to be in place when
> =org-babel-expand-src-block= calls
> =org-babel-variable-assignments:shell= in the simple code expansion
> case. But that
> would be a bit hacky since the generic =org-babel-expand-src-block=
> function should
> not override variables needed in just one subclass of backends. It would be
> cleaner to have different functions =org-babel-variable-assignments:XXX=
> for the
> different shells.
Thank you for the report.
Since you went pretty far already into the analysis, would you want to
provide a patch implementing your suggestion, i.e., have different
functions =org-babel-variable-assignments:XXX= for the different shells?
Regards,
--
Nicolas Goaziou
prev parent reply other threads:[~2017-05-08 9:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-07 15:47 Bug: org-babel-expand-src-block expands sh blocks independent of shell defined by src block [9.0.5 (9.0.5-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20170210/)] Derek Feichtinger
2017-05-08 9:54 ` Nicolas Goaziou [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shkf65cp.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=derek.feichtinger@psi.ch \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).