hi. i did a bit of poking around. here are my findings, but i'm not
conversant enough with the semantics and interconnectivity of org-mode
to know what should be done.
to summarize: if a Babel awk script returns something that starts out
with a left paren ("("), i get "Code block returned no value".
basically, org-babel-execute:awk calls org-babel-import-elisp-from-file:
which calls org-babel-string-read [1] with each cell of the result.
org-babel-string-read calls org-babel-read. org-babel-read
looks to see if the first character of the cell is one of {[,(,',`} and,
if it is, tries to evaluate the cell as e-lisp. in my case (below),
what is in the cell is "(minimal)" and since there is no minimal
function in e-lisp, an error is thrown.
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 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?
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.
