From: Daniele Pizzolli <dan@toel.it>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] inline src block results can be removed
Date: Tue, 25 Nov 2014 09:04:45 +0100 [thread overview]
Message-ID: <fcc34d957e3dc028265770a67c06fa09@toel.it> (raw)
In-Reply-To: <8fd5459682651e00af0f99df81319db3@toel.it>
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
next prev parent reply other threads:[~2014-11-25 8:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-24 11:12 [PATCH] inline src block results can be removed Daniele Pizzolli
2014-11-25 8:04 ` Daniele Pizzolli [this message]
2014-11-25 9:52 ` Andreas Leha
-- strict thread matches above, loose matches on Subject: below --
2014-11-12 0:49 Charles C. Berry
2014-11-12 1:10 ` Andreas Leha
2014-11-12 6:58 ` Charles C. Berry
2014-11-12 19:34 ` Aaron Ecay
2014-11-12 23:47 ` Charles C. Berry
2014-11-13 17:48 ` Nicolas Goaziou
2014-11-13 19:06 ` Andreas Leha
2014-11-14 17:43 ` Charles C. Berry
2014-11-14 20:39 ` Nicolas Goaziou
2014-11-14 23:04 ` Aaron Ecay
2014-11-16 0:10 ` Nicolas Goaziou
2014-11-15 20:22 ` Charles C. Berry
2014-11-16 23:23 ` Nicolas Goaziou
2014-11-24 9:48 ` Daniele Pizzolli
2014-11-24 10:18 ` Andreas Leha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fcc34d957e3dc028265770a67c06fa09@toel.it \
--to=dan@toel.it \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).