org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Derek Feichtinger]

When org-export-babel-evaluate is set to nil, I see a different behavior 
now as compared to earlier versions of org.

Now it seems that all header arguments of a code block are ignored, 
including the arguments to the :exports setting. Even when I have set 
":exports results" or ":exports code" I always get code and results 
exported in the resulting document. If org-export-babel-evaluate is set 
to t then everything behaves the way I was used to, ":exports results" 
just exports the results and when set to "code" just the code is exported.

I think that this should be considered a bug. I frequently (even most of 
the time) want to evaluate the org blocks manually, not upon export, but 
I want to be able to define whether only the results should be visible 
in the exported document. For generated pictures this is usually the 
normal case.

I am using org 9.0.5 from MELPA now, and I can't completely say when 
this changed, but I am very sure that a few weeks ago the behavior was 
different, since I am using org a lot for preparing documents.

Simple test document:

#####################
* Test

   #+BEGIN_SRC elisp :results output :exports code
     (princ (format "This should only export the code\nemacs %s\norg %s" 
emacs-version org-version))
   #+END_SRC

   #+RESULTS:
   : This should only export the code
   : emacs 25.1.1
   : org 9.0.5

   #+BEGIN_SRC elisp :results output :exports results
     (princ (format "This should only export the results\nemacs %s\norg 
%s" emacs-version org-version))
   #+END_SRC

   #+RESULTS:
   : This should only export the results
   : emacs 25.1.1
   : org 9.0.5


* COMMENT Org babel settings
Local Variables:
org-export-babel-evaluate: nil
End:

####################
ASCII exported document when org-export-babel-evaluate: nil


1 Test
======

   ,----
   | (princ (format "This should only export the code\nemacs %s\norg %s" 
emacs-version org-version))
   `----

   ,----
   | This should only export the code
   | emacs 25.1.1
   | org 9.0.5
   `----

   ,----
   | (princ (format "This should only export the results\nemacs %s\norg 
%s" emacs-version org-version))
   `----

   ,----
   | This should only export the results
   | emacs 25.1.1
   | org 9.0.5
   `----

####################
ASCII exported document when org-export-babel-evaluate: t

1 Test
======

   ,----
   | (princ (format "This should only export the code\nemacs %s\norg %s" 
emacs-version org-version))
   `----

   ,----
   | This should only export the results
   | emacs 25.1.1
   | org 9.0.5
   `----


Best regards,
Derek


-- 
Paul Scherrer Institut
Dr. Derek Feichtinger                   Phone:   +41 56 310 47 33
Section Head Science-IT                 Email: derek.feichtinger@psi.ch
Building/Room No. WHGA/U126
CH-5232 Villigen PSI

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Charles C. Berry]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Mon, 20 Feb 2017, Derek Feichtinger wrote:

> When org-export-babel-evaluate is set to nil, I see a different behavior now 
> as compared to earlier versions of org.

Indeed.

It is now *obsolete* and its behavior has intentionally been changed as 
noted here:

,----[ C-h v org-export-babel-evaluate RET ]
| org-export-babel-evaluate is a variable defined in ‘org-compat.el’.
| Its value is t
|
|   This variable is an alias for ‘org-export-use-babel’.
|   This variable is obsolete since Org 9.1;
|   use ‘org-export-use-babel’ instead.
|
| Documentation:
| Switch controlling code evaluation and header processing during export.
| When set to nil no code will be evaluated as part of the export
| process and no header arguments will be obeyed.  When set to
| ‘inline-only’, only inline code blocks will be executed.  Users
| who wish to avoid evaluating code on export should use the header
| argument ‘:eval never-export’.
|
| You can customize this variable.
|
| [back]
`----

and here

 	 (info "(org) Exporting code blocks")

> I think that this should be considered a bug.

Allowing header args to be processed (as before) also allows for arbitrary 
code to be executed.  The point of setting ‘org-export-use-babel’ or 
`org-export-babel-evaluate' to nil was to prevent this.  For that reason 
the former behavior was a bug.


Chuck

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Derek Feichtinger]

Hi Chuck

On 21.02.2017 00:54, Charles C. Berry wrote:
> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>
>> When org-export-babel-evaluate is set to nil, I see a different 
>> behavior now as compared to earlier versions of org.
>
> Indeed.
>
> It is now *obsolete* and its behavior has intentionally been changed 
> as noted here:
>
In my current version from MELPA the info text is not yet reflecting 
this change. Thanks for pointing me to it.


> ,----[ C-h v org-export-babel-evaluate RET ]
> | org-export-babel-evaluate is a variable defined in ‘org-compat.el’.
> | Its value is t
> |
> |   This variable is an alias for ‘org-export-use-babel’.
> |   This variable is obsolete since Org 9.1;
> |   use ‘org-export-use-babel’ instead.
>
> and here
>
>      (info "(org) Exporting code blocks")
>
>> I think that this should be considered a bug.
>
> Allowing header args to be processed (as before) also allows for 
> arbitrary code to be executed.  The point of setting 
> ‘org-export-use-babel’ or `org-export-babel-evaluate' to nil was to 
> prevent this.  For that reason the former behavior was a bug.
>
OK. I can see that one wants to prevent most header args of babel blocks 
from being reeavaluated, but the :exports argument does not affect 
evaluation, but simply the representation of the result exported to the 
target document. So, I think that this argument still should be 
observed. Otherwise the resulting document would be completely changed 
once I introduce ‘org-export-use-babel’. I might want to introduce it to 
conserve the current code block results, while still being very much 
interested in exporting it to a different format, or re-exporting it at 
a later point (after having added new chapters that are manually evaluated).

So, I still feel that this is a very much needed functionality that has 
been lost on the way. I have made many documents over the last few years 
that relied on this functionality, e.g. files collecting logs or 
producing analysis results that were dependent on a particular state of 
a system at that moment of time. I hope that the observing of the 
:exports argument can be reintroduced.

Derek

-- 
Paul Scherrer Institut
Dr. Derek Feichtinger                   Phone:   +41 56 310 47 33
Section Head Science-IT                 Email: derek.feichtinger@psi.ch
Building/Room No. WHGA/U126
CH-5232 Villigen PSI

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Aaron Ecay]

Hi Chuck,

2017ko otsailak 20an, "Charles C. Berry"-ek idatzi zuen:

[...]


> 
> Allowing header args to be processed (as before) also allows for arbitrary 
> code to be executed.  The point of setting ‘org-export-use-babel’ or 
> `org-export-babel-evaluate' to nil was to prevent this.  For that reason 
> the former behavior was a bug.

Iʼm not sure I agree that itʼs so simple.  There are still ways to execute
arbitrary code on export independently of babel (e.g. eval macros).  The
advice to use o-e-babel-evaluate for security was never (IMO) correct –
the only properly secure wat to export untrusted documents would involve
some kind of sandboxing of the emacs executable.

The original bug that led to the change in the behavior of o-e-b-e was
that a misspecified var header would lead to an error on export
<http://thread.gmane.org/gmane.emacs.orgmode/106767>.  I think the
change was an overreaction to that problem (and insofar as it changed
the long-standing behavior of that variable, a regression).  Export
(c/sh)ould still respect static (i.e. non-executable) header args;
o-e-b-e should only inhibit executable args.  From the standpoint of
implementation, the execution of code in header args can be controlled
by the inhibit-eval argument to org-babel-read and the light argument to
org-babel-get-src-block-info (and both functions might need to be
extended to look at dynamic variables in addition to these arguments).

Taking a step back, I would ask what justifies o-e-b-eʼs existence at
all.  This thread demonstrates that itʼs not the right way to prevent
babel blocks from executing on export.  Itʼs also not a good solution to
the security issue.  Given the potential for confusion, Iʼd be in favor
of deprecating it entirely unless thereʼs some compelling reason for it
to exist that Iʼve overlooked.

-- 
Aaron Ecay

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Charles C. Berry]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Mon, 20 Feb 2017, Derek Feichtinger wrote:

> Hi Chuck
>
> On 21.02.2017 00:54, Charles C. Berry wrote:
>> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>> 
>>> When org-export-babel-evaluate is set to nil, I see a different behavior 
>>> now as compared to earlier versions of org.
>> 
>> Indeed.
>> 
>> It is now *obsolete* and its behavior has intentionally been changed as 
>> noted here:
>>


> So, I still feel that this is a very much needed functionality that has been 
> lost on the way.

Nothing is lost here.

Reread the part of my post that you deleted in your reply:

: | ...  Users
: | who wish to avoid evaluating code on export should use the header
: | argument ‘:eval never-export’.
: |

which is how to do what you want.

And maybe review how to set header args buffer wide or system-wide.

HTH,

Chuck

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Charles C. Berry]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Tue, 21 Feb 2017, Aaron Ecay wrote:

> Hi Chuck,
>
> 2017ko otsailak 20an, "Charles C. Berry"-ek idatzi zuen:
>
> [...]
>
>
>>
>> Allowing header args to be processed (as before) also allows for arbitrary
>> code to be executed.  The point of setting ‘org-export-use-babel’ or
>> `org-export-babel-evaluate' to nil was to prevent this.  For that reason
>> the former behavior was a bug.
>
> Iʼm not sure I agree that itʼs so simple.  There are still ways to execute
> arbitrary code on export independently of babel (e.g. eval macros).  The
> advice to use o-e-babel-evaluate for security was never (IMO) correct –
> the only properly secure wat to export untrusted documents would involve
> some kind of sandboxing of the emacs executable.
>

Fair enough.

[snip]

>
> Taking a step back, I would ask what justifies o-e-b-eʼs existence at
> all.  This thread demonstrates that itʼs not the right way to prevent
> babel blocks from executing on export.  Itʼs also not a good solution to
> the security issue.  Given the potential for confusion, Iʼd be in favor
> of deprecating it entirely unless thereʼs some compelling reason for it
> to exist that Iʼve overlooked.

In view of your point above about `eval' macros, I do not disagree.

Chuck.

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Colin Baxter]

Hi.

On Tue, Feb 21 2017, Charles C. Berry wrote:

> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>
>> Hi Chuck
>>
>> On 21.02.2017 00:54, Charles C. Berry wrote:
>>> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>>>
>>>> When org-export-babel-evaluate is set to nil, I see a different
>>>> behavior now as compared to earlier versions of org.
>>>
>>> Indeed.
>>>
>>> It is now *obsolete* and its behavior has intentionally been
>>> changed as noted here:
>>>
>
>
>> So, I still feel that this is a very much needed functionality that
>> has been lost on the way.
>
> Nothing is lost here.
>
> Reread the part of my post that you deleted in your reply:
>
> : | ...  Users
> : | who wish to avoid evaluating code on export should use the header
> : | argument ‘:eval never-export’.
> : |
>
> which is how to do what you want.
>
> And maybe review how to set header args buffer wide or system-wide.
>

I agree very much with the sentiments expressed by Derek
Feichtinger. The old org-export-babel-evaluate allowed a setting to be made
for one or several files. Perhaps I've not understood correctly, but the
new arrangement would seem to suggest that the user has to insert what
they want at each src_code block.

Best wishes,

C.

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Derek Feichtinger]

Hi Colin

On 22.02.2017 16:27, Colin Baxter wrote:
> Hi.
>
> On Tue, Feb 21 2017, Charles C. Berry wrote:
>
>> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>>
>>> Hi Chuck
>>>
>>> On 21.02.2017 00:54, Charles C. Berry wrote:
>>>> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>>>>
>>>>> When org-export-babel-evaluate is set to nil, I see a different
>>>>> behavior now as compared to earlier versions of org.
>>>> Indeed.
>>>>
>>>> It is now *obsolete* and its behavior has intentionally been
>>>> changed as noted here:
>>>>
>>
>>> So, I still feel that this is a very much needed functionality that
>>> has been lost on the way.
>> Nothing is lost here.
>>
>> Reread the part of my post that you deleted in your reply:
>>
>> : | ...  Users
>> : | who wish to avoid evaluating code on export should use the header
>> : | argument ‘:eval never-export’.
>> : |
>>
>> which is how to do what you want.
>>
>> And maybe review how to set header args buffer wide or system-wide.
>>
> I agree very much with the sentiments expressed by Derek
> Feichtinger. The old org-export-babel-evaluate allowed a setting to be made
> for one or several files. Perhaps I've not understood correctly, but the
> new arrangement would seem to suggest that the user has to insert what
> they want at each src_code block.
>
Based on the documentation one can set the header arguments system wide 
using these variables:

org-babel-default-header-args (for all)
org-babel-default-header-args:<lang>   (language specific)

File wide using PROPERTY:
#+PROPERTY: header-args :eval never-export

Org heading wide using a local property setting:
      * sample header
        :PROPERTIES:
        :header-args:    :eval never-export
        :END:

The last two ways I tested. So, in the end, with some changes to most of 
my files I can get the same behavior again, which is good.

It's a matter of taste or use case whether to define the default 
behavior to eval on export. I would have made the case the eval on 
export is the more rare use case. I almost never have this, except for 
certain kinds of reports, e.g. if you want to gather the state of a 
server with a number of prepared queries in the org file. For me, most 
org files are like a number of measurements taken at a certain point in 
time, and I want to conserve the output of the evaluation exactly like 
it was. E.g. when working at speeding up code, I very much like to do 
the whole thing inside of an org file where I document the speed 
measurements, my changes to code and what the effect was. So, more like 
some kind of interactive lab journal.

But as I said, it is a matter of taste, and I am happy that I can get 
the original functionality without too much effort.

Best regards,
Derek


-- 
Paul Scherrer Institut
Dr. Derek Feichtinger                   Phone:   +41 56 310 47 33
Section Head Science-IT                 Email: derek.feichtinger@psi.ch
Building/Room No. WHGA/U126
CH-5232 Villigen PSI

Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Colin Baxter]

On Wed, Feb 22 2017, Derek Feichtinger wrote:

Dear Derek,

> Hi Colin
>
> On 22.02.2017 16:27, Colin Baxter wrote:
>> Hi.
>>
>> On Tue, Feb 21 2017, Charles C. Berry wrote:
>>
>>> On Mon, 20 Feb 2017, Derek Feichtinger wrote:
>>>
--------- snip ---------
> Based on the documentation one can set the header arguments system wide 
> using these variables:
>
> org-babel-default-header-args (for all)
> org-babel-default-header-args:<lang>   (language specific)
>
> File wide using PROPERTY:
>
> #+PROPERTY: header-args :eval never-export
>
> Org heading wide using a local property setting:
>       * sample header
>         :PROPERTIES:
>         :header-args:    :eval never-export
>         :END:
>
> The last two ways I tested. So, in the end, with some changes to most of 
> my files I can get the same behavior again, which is good.
>
> It's a matter of taste or use case whether to define the default 
> behavior to eval on export. I would have made the case the eval on 
> export is the more rare use case. I almost never have this, except for 
> certain kinds of reports, e.g. if you want to gather the state of a 
> server with a number of prepared queries in the org file. For me, most 
> org files are like a number of measurements taken at a certain point in 
> time, and I want to conserve the output of the evaluation exactly like 
> it was. E.g. when working at speeding up code, I very much like to do 
> the whole thing inside of an org file where I document the speed 
> measurements, my changes to code and what the effect was. So, more like 
> some kind of interactive lab journal.
>
> But as I said, it is a matter of taste, and I am happy that I can get 
> the original functionality without too much effort.
>
> Best regards,
> Derek

--------------- snip ---------

Thank you, I really appreciate this information. You have saved me a
couple of hours work. I'll probably end up setting
org-babel-default-header-args as a local variable.

Thanks again.

Best wishes.