* org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
@ 2017-02-20 22:02 Derek Feichtinger
2017-02-20 23:54 ` Charles C. Berry
0 siblings, 1 reply; 9+ messages in thread
From: Derek Feichtinger @ 2017-02-20 22:02 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-20 22:02 org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed Derek Feichtinger
@ 2017-02-20 23:54 ` Charles C. Berry
2017-02-21 6:05 ` Derek Feichtinger
2017-02-21 10:51 ` Aaron Ecay
0 siblings, 2 replies; 9+ messages in thread
From: Charles C. Berry @ 2017-02-20 23:54 UTC (permalink / raw)
To: Derek Feichtinger; +Cc: emacs-orgmode
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-20 23:54 ` Charles C. Berry
@ 2017-02-21 6:05 ` Derek Feichtinger
2017-02-21 16:37 ` Charles C. Berry
2017-02-21 10:51 ` Aaron Ecay
1 sibling, 1 reply; 9+ messages in thread
From: Derek Feichtinger @ 2017-02-21 6:05 UTC (permalink / raw)
To: Charles C. Berry; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-20 23:54 ` Charles C. Berry
2017-02-21 6:05 ` Derek Feichtinger
@ 2017-02-21 10:51 ` Aaron Ecay
2017-02-21 16:40 ` Charles C. Berry
1 sibling, 1 reply; 9+ messages in thread
From: Aaron Ecay @ 2017-02-21 10:51 UTC (permalink / raw)
To: Charles C. Berry, Derek Feichtinger; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-21 6:05 ` Derek Feichtinger
@ 2017-02-21 16:37 ` Charles C. Berry
2017-02-22 15:27 ` Colin Baxter
0 siblings, 1 reply; 9+ messages in thread
From: Charles C. Berry @ 2017-02-21 16:37 UTC (permalink / raw)
To: Derek Feichtinger; +Cc: emacs-orgmode
[-- 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-21 10:51 ` Aaron Ecay
@ 2017-02-21 16:40 ` Charles C. Berry
0 siblings, 0 replies; 9+ messages in thread
From: Charles C. Berry @ 2017-02-21 16:40 UTC (permalink / raw)
To: Aaron Ecay; +Cc: emacs-orgmode, Derek Feichtinger
[-- 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-21 16:37 ` Charles C. Berry
@ 2017-02-22 15:27 ` Colin Baxter
2017-02-22 15:45 ` Derek Feichtinger
0 siblings, 1 reply; 9+ messages in thread
From: Colin Baxter @ 2017-02-22 15:27 UTC (permalink / raw)
To: Charles C. Berry; +Cc: emacs-orgmode, Derek Feichtinger
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-22 15:27 ` Colin Baxter
@ 2017-02-22 15:45 ` Derek Feichtinger
2017-02-22 18:56 ` Colin Baxter
0 siblings, 1 reply; 9+ messages in thread
From: Derek Feichtinger @ 2017-02-22 15:45 UTC (permalink / raw)
To: Colin Baxter, Charles C. Berry; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
2017-02-22 15:45 ` Derek Feichtinger
@ 2017-02-22 18:56 ` Colin Baxter
0 siblings, 0 replies; 9+ messages in thread
From: Colin Baxter @ 2017-02-22 18:56 UTC (permalink / raw)
To: Derek Feichtinger; +Cc: emacs-orgmode, Charles C. Berry
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-02-22 18:56 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-20 22:02 org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed Derek Feichtinger
2017-02-20 23:54 ` Charles C. Berry
2017-02-21 6:05 ` Derek Feichtinger
2017-02-21 16:37 ` Charles C. Berry
2017-02-22 15:27 ` Colin Baxter
2017-02-22 15:45 ` Derek Feichtinger
2017-02-22 18:56 ` Colin Baxter
2017-02-21 10:51 ` Aaron Ecay
2017-02-21 16:40 ` Charles C. Berry
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).