emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] babel awk with table input: Code block produced no output.


From: Thomas S. Dye
Subject: Re: [O] babel awk with table input: Code block produced no output.
Date: Sun, 05 Aug 2012 15:36:21 -1000

Hi Greg,

:results output sounds right for awk as a report formatter.  I'm
wondering if there is a need for :results value with awk?

All the best,
Tom

Greg Minshall <address@hidden> writes:

> 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.
>
>

-- 
Thomas S. Dye
http://www.tsdye.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]