Tom Regner <t...@goochesa.de> writes: > Eric Schulte <eric.schu...@gmx.com> writes: > >>> >>> But I'm often bitten by the distinction between export and tangling -- >>> :padline, :shebang come to mind, where I expected org-babel to honour >>> the setting in both cases. >>> >> >> Could you describe a use case where these options would be used for >> exporting and would be preferable to simply including the padding lines >> or the shebang literally in the code block? > > I use an LP org-document with zsh-codefragments to generate a CLIF > testplan - the script is tangled, then executed and the output -- the > generated .ctp file -- exported. In this case I'd prefere it to have the > shell from the :shebang option used to run the tangled program, not > /bin/sh, so that exporting the output inside the document and running > the tangled program standalone produce the same result. > > At the moment I have to set the shell document- or session-wide to zsh > to get reproducible behaviour. > > Whenever the export/execution is part of the generated document and of > the generated product (the tangled code) I would like it, not to have to > sides to configure. > > I don't know, if I make myself clear -- If not, please tell me so and I > try to distill an example out of the cases I encountered at work, where > I was wondering why some things did not work as I expected. >
I think I understand now, so it is "execution" not "export" behavior which could make use of the :shebang header argument. I suppose that it would be possible to allow the :shebang header argument to silently override the value of the `org-babel-sh-command' variable when it is present. I just pushed up a patch which adds this behavior. It does result in some odd new possibilities, such as the following. #+begin_src sh :shebang #!/bin/cat foo #+end_src #+RESULTS: | #!/bin/cat | | | | foo | Best, > > Kind regards, > Tom -- Eric Schulte http://cs.unm.edu/~eschulte/
