From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniele Pizzolli Subject: Re: [PATCH] inline src block results can be removed Date: Tue, 25 Nov 2014 09:04:45 +0100 Message-ID: References: <8fd5459682651e00af0f99df81319db3@toel.it> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtB7K-00015T-Kd for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 03:05:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtB7A-0001Yy-AV for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 03:04:58 -0500 Received: from relay5-d.mail.gandi.net ([2001:4b98:c:538::197]:45647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtB79-0001YR-Vw for emacs-orgmode@gnu.org; Tue, 25 Nov 2014 03:04:48 -0500 Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id F124741C04B for ; Tue, 25 Nov 2014 09:04:46 +0100 (CET) Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rMx7Xupce-OV for ; Tue, 25 Nov 2014 09:04:45 +0100 (CET) Received: from webmail.gandi.net (unknown [10.58.1.145]) (Authenticated sender: me@toel.it) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 887C341C073 for ; Tue, 25 Nov 2014 09:04:45 +0100 (CET) In-Reply-To: <8fd5459682651e00af0f99df81319db3@toel.it> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org On 2014-11-24 12:12, Daniele Pizzolli wrote: > On 2014-11-24 11:18, Andreas Leha wrote: >> Hi Daniele, >> >> I think your wishlist is somewhere further down the road. I usually >> implement some of your points in the src_language. I see that it >> would >> be nice if org supported these use cases, but I would see them as part >> of the LOB or maybe in some package in contrib rather than in core >> org/babel. >> >> For that, I'd argue removable inline results that can be exported >> without special formatting would be all that is needed to support your >> wishlist. > > Hi Andreas, > > sure, I think I will start getting the string I needed from > src_language. But in some language is really hard to get facilities > for text manipulation while the output as table generally supported. > And I also think that the fine grained control of the layout of the > inline sentence pertains to the org layer. Hi Andreas, Yesterday I forgot to mention another reason because I think that the formatting of the results pertains to the org layer and not to the original language. It's about proper boundaries and untrusted or limited trust of the babel code. By default I wish to run untrusted code and display in a safely manner the result. This is already possible by remote code evaluation (but I not really checked if the output is always safely escaped before the insertion in the org buffer). Using the source language for outputting org-code is a viable workaround for my needs but in the long run I will prefer to not include some potential harmful generated org code. I double checked about the output escaping right now. I guessed that the output in the raw mode was safely escaped. But it really seems the opposite: [[info:org#Results]]. However it seems that the RESULTS code are not subsequently evaluated even with: #+BEGIN_SRC elisp (org-babel-do-load-languages 'org-babel-load-languages '((sh . t))) (setq org-export-babel-evaluate t) #+END_SRC Example: #+NAME: is-this-safe-or-not #+BEGIN_SRC sh :result output raw printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo true; echo false}' #+END_SRC # TODO: the pipe causes a bug... #+RESULTS: is-this-safe-or-not : Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo true; echo false} So now I am more confused than before... Has anybody a proof or a counterexample that is (im)possible to run safely untrusted code on (untrusted) remote host and still have the local buffer trusted? By the way I really wanted to write: #+NAME: problem-with-pipes... #+BEGIN_SRC sh :result output raw printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo true || echo false}' #+END_SRC #+RESULTS: problem-with-pipes... | Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo true | | echo false} | I guess that something is wrong here: Org-mode version 8.3beta (release_8.3beta-485-gf70439 @ /home/user/.emacs.d/el-get/org-mode/lisp/) Maybe we need a new result format for safe output or am I missing something? Thanks in advance, Daniele