so, the first question is, are the semantics of parsing results such
that random e-lisp-looking code should be executed? (this seems
dangerous, but may nevertheless be the intended semantics.) if one did
*not* want that behavior, one can call org-babel-read with the
inhibit-lisp-eval parameter 't, which causes it to *not* try to execute
any embedded lisp-looking code [2].
The reading of values that look like lisp as lisp is intended behavior
of the `org-babel-read' function at large (e.g., this is how we are able
to pass in the current file name through a header argument), however I
agree that this should probably not be the default behavior when reading
results from a code block. It is much more likely that a person will
intentionally embed elisp in a header argument, but much less likely
that someone would intentionally write an awk script which returns elisp
(and if that is their goal they can simple pass the awk output to an
emacs-lisp code block).
For this reason I've just pushed up a change which does as you suggest
and inhibits lisp evaluation in the `org-babel-import-elisp-from-file'
function which is only used to import emacs-lisp results from code
blocks.
If anyone is relying on the current behavior please complain about this
change and we can look at other options.
the error that eval throws is caught by
org-babel-import-elisp-from-file, which then just silently returns a
nil. the second question is, should it report an error to the user?
This will now report the error with a message, but will still return nil
for the table cell's value.
Thanks,
cheers, Greg Minshall
hi. it appears that a left or right paren in an entry in a table makes
awk not execute. here's an example (change :stdin fails to :stdin
works to see it work). cheers, Greg
#+tblname: fails
| proto | no c code ||
| pscl | c code, just fine ||
| quadprog | (minimal) c code, just fine ||
#+tblname: works
| proto | no c code ||
| pscl | c code, just fine ||
| quadprog | minimal c code, just fine ||
#+begin_src awk :stdin fails
BEGIN {
print starting
}
{
print $0
}
#+end_src
[1] in spite of its documentation, i'm not sure what
org-babel-string-read does. i thought it was removing quotation marks
from strings (but wasn't sure why). but, running this in *scratch*
gives:
(org-babel-string-read this is \a\ test)
a
rather than this is a test, as i had assumed. maybe that was a bogus
test?
[2] changing org-babel-string-read to call org-babel-read with
inhibit-lisp-eval 't causes *my code* to work. my code *also* works if
i say :results output or :results scalar; i will defensively use one
of these for my code.
--
Eric Schulte
http://cs.unm.edu/~eschulte
