Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
Can confirm that. Thanks for your work! Best, Ruiyang > On Nov 1, 2020, at 4:44 PM, Kyle Meyer wrote: > > Kyle Meyer writes: > >> It looks like the query went away with dbb375fdf (Simplify Babel calls >> evaluation, 2016-06-16), which was included in the 9.0 release. Based >> on a quick glance at that commit, I don't think that was an intentional >> change. >> >> I won't take a closer look at this until at least this weekend, though. >> I'd be very happy if someone beat me to it. > > Should be fixed by 20374f69e. That includes a regression test that will > hopefully prevent an unintended change in either direction (no prompting > or repeat prompting).
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
Kyle Meyer writes: > It looks like the query went away with dbb375fdf (Simplify Babel calls > evaluation, 2016-06-16), which was included in the 9.0 release. Based > on a quick glance at that commit, I don't think that was an intentional > change. > > I won't take a closer look at this until at least this weekend, though. > I'd be very happy if someone beat me to it. Should be fixed by 20374f69e. That includes a regression test that will hopefully prevent an unintended change in either direction (no prompting or repeat prompting).
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
Berry, Charles" via "General discussions about Org-mode. writes: > FWIW, it doesn't seem like an accident. You might ping the author of this > commit: No, that change was to suppress an _additional_ confirmation that was triggered by some internal implementation details. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
Just on a whim, I changed `org-babel-exp-results' by deleting (let (org-confirm-babel-evaluate-NOT) and the matching right parenthesis. Now I get a single prompt to confirm evaluation using Ruiyang's ECM. HTH, Chuck > On Oct 28, 2020, at 8:16 PM, Kyle Meyer wrote: > > 吴锐扬 writes: > >> The author explained his motivation for the commit in the mailing list >> before it got applied: >> >>> That's because lob calls get wrapped internally in an anonymous >>> emacs-lisp source block that then feeds through the result from the >>> actual call as elisp. The attached patch should suppress the >>> confirmation for the wrapper call. To the best of my knowledge nothing >>> dangerous can happen with that evaluation and all confirmations for the >>> call stack down from there have already taken place according to the >>> users' setup. > > Just for reference: it looks like that's > > > https://urldefense.com/v3/__https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid__;!!LLK065n_VXAQ!29k-PVwb9XnRUW2w0NBea_sA5uaG3P1Ck0lJ_EyddjelOaIrJGxmvvR28RAyZpjHiQ$ > > >> If I understand correctly, executing a lob call would trigger two user >> confirmations in the past, and this commit was meant to suppress one >> of the two confirmations. (I may be wrong since I am a fairly new user >> of org mode.) > > Thanks for digging. Indeed, if you go back to the parent of 56bf3d789 > (Babel: avoid superfluous confirmation for internal wrapper, > 2013-04-10), there are two queries. On that commit, there is one. > >> Now there is no confirmation at all. IMHO, there should be exactly >> one confirmation ideally. > > It looks like the query went away with dbb375fdf (Simplify Babel calls > evaluation, 2016-06-16), which was included in the 9.0 release. Based > on a quick glance at that commit, I don't think that was an intentional > change. > > I won't take a closer look at this until at least this weekend, though. > I'd be very happy if someone beat me to it.
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
吴锐扬 writes: > The author explained his motivation for the commit in the mailing list before > it got applied: > >> That's because lob calls get wrapped internally in an anonymous >> emacs-lisp source block that then feeds through the result from the >> actual call as elisp. The attached patch should suppress the >> confirmation for the wrapper call. To the best of my knowledge nothing >> dangerous can happen with that evaluation and all confirmations for the >> call stack down from there have already taken place according to the >> users' setup. Just for reference: it looks like that's https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid > If I understand correctly, executing a lob call would trigger two user > confirmations in the past, and this commit was meant to suppress one > of the two confirmations. (I may be wrong since I am a fairly new user > of org mode.) Thanks for digging. Indeed, if you go back to the parent of 56bf3d789 (Babel: avoid superfluous confirmation for internal wrapper, 2013-04-10), there are two queries. On that commit, there is one. > Now there is no confirmation at all. IMHO, there should be exactly > one confirmation ideally. It looks like the query went away with dbb375fdf (Simplify Babel calls evaluation, 2016-06-16), which was included in the 9.0 release. Based on a quick glance at that commit, I don't think that was an intentional change. I won't take a closer look at this until at least this weekend, though. I'd be very happy if someone beat me to it.
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
The author explained his motivation for the commit in the mailing list before it got applied: > That's because lob calls get wrapped internally in an anonymous > emacs-lisp source block that then feeds through the result from the > actual call as elisp. The attached patch should suppress the > confirmation for the wrapper call. To the best of my knowledge nothing > dangerous can happen with that evaluation and all confirmations for the > call stack down from there have already taken place according to the > users' setup. If I understand correctly, executing a lob call would trigger two user confirmations in the past, and this commit was meant to suppress one of the two confirmations. (I may be wrong since I am a fairly new user of org mode.) Now there is no confirmation at all. IMHO, there should be exactly one confirmation ideally. But you are right, I should just copy the author on this. Thanks, Ruiyang > On Oct 28, 2020, at 10:26 AM, Berry, Charles wrote: > > FWIW, it doesn't seem like an accident. You might ping the author of this > commit: > > $ git log -S "(let (org-confirm-babel-evaluate)" > commit 56bf3d789146fcd3c9f82d875de28c394fe593a0 > Author: Achim Gratz > Date: Wed Apr 10 20:28:31 2013 +0200 > >Babel: avoid superfluous confirmation for internal wrapper > >* lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation > of the emacs-lisp wrapper execution around a lob call. > >* lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation > of the emacs-lisp wrapper execution around a lob call. > > > > HTH, > > Chuck > >> On Oct 28, 2020, at 4:32 AM, Eric S Fraga wrote: >> >> On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote: >>> I have org-confirm-babel-evaluate set to t by default. With this, I >>> expect to be queried with the execution of every code block or lob >>> call. However, this does not happen when exporting lob calls (to latex >>> for example). Here is an example: >> >> Confirmed with fairly recent org from git with >> org-confirm-babel-evaluate set to t. Does seem a little strange. It >> doesn't bother me much as I don't export org files that I haven't >> created myself but it does appear to be a hole. >> >> -- >> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty >> >> >
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
FWIW, it doesn't seem like an accident. You might ping the author of this commit: $ git log -S "(let (org-confirm-babel-evaluate)" commit 56bf3d789146fcd3c9f82d875de28c394fe593a0 Author: Achim Gratz Date: Wed Apr 10 20:28:31 2013 +0200 Babel: avoid superfluous confirmation for internal wrapper * lisp/ob-exp.el (org-babel-exp-results): Suppress user confirmation of the emacs-lisp wrapper execution around a lob call. * lisp/ob-lob.el (org-babel-lob-execute): Suppress user confirmation of the emacs-lisp wrapper execution around a lob call. HTH, Chuck > On Oct 28, 2020, at 4:32 AM, Eric S Fraga wrote: > > On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote: >> I have org-confirm-babel-evaluate set to t by default. With this, I >> expect to be queried with the execution of every code block or lob >> call. However, this does not happen when exporting lob calls (to latex >> for example). Here is an example: > > Confirmed with fairly recent org from git with > org-confirm-babel-evaluate set to t. Does seem a little strange. It > doesn't bother me much as I don't export org files that I haven't > created myself but it does appear to be a hole. > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty > >
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
On Wednesday, 14 Oct 2020 at 16:18, 吴锐扬 wrote: > I have org-confirm-babel-evaluate set to t by default. With this, I > expect to be queried with the execution of every code block or lob > call. However, this does not happen when exporting lob calls (to latex > for example). Here is an example: Confirmed with fairly recent org from git with org-confirm-babel-evaluate set to t. Does seem a little strange. It doesn't bother me much as I don't export org files that I haven't created myself but it does appear to be a hole. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty
Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls
This is just a follow up to see if anyone have insights on this matter. Thanks Ruiyang > On Oct 14, 2020, at 1:18 PM, 吴锐扬 wrote: > > Hi, > > I have org-confirm-babel-evaluate set to t by default. With this, I expect to > be queried with the execution of every code block or lob call. However, this > does not happen when exporting lob calls (to latex for example). Here is an > example: > __ > > 1. Exporting code block (with evaluation) > #+name: foo > #+begin_src emacs-lisp :exports both > (message "hello world!") > #+end_src > > When exporting this to latex, I get queried as expected. And there is no way > to suppress the query unless I change org-confirm-babel-evaluate to nil. > > 2. Exporting lob call > #+name: foo > #+begin_src emacs-lisp > (message "hello world!") > #+end_src > > #+call: foo() > > When exporting this to latex, I don’t get queried. This seems dangerous to me. > __ > > I find it hard to explain this inconsistency. If org-confirm-babel-evaluate > is designed to be a protective layer, then a user might export an org file > that includes malicious code along with a lob call, while unawarely execute > that code without being warned. This seems to defeat the purpose of > org-confirm-babel-evaluate. > > As I searched the archive, I found this change was introduced in the > following thread: > https://lists.gnu.org/archive/html/emacs-orgmode/2013-04/msg00764.html > > + (let (org-confirm-babel-evaluate) > + (org-babel-execute-src-block nil info)) > > Do you think this is the intended behavior of org-confirm-babel-evaluate, or > am I missing something? > > Thanks, > Ruiyang >
