emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Dan Davison <dandavison7@gmail.com>
To: "Sébastien Vauban"
	<public-wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@plane.gmane.org>
Cc: public-emacs-orgmode-mXXj517/zsQ@plane.gmane.org
Subject: Re: [Babel] Reporting 2 problems of code execution
Date: Mon, 29 Nov 2010 19:49:19 +0000	[thread overview]
Message-ID: <87fwujoqps.fsf@gmail.com> (raw)
In-Reply-To: <80pqtoijrw.fsf@missioncriticalit.com> ("Sébastien Vauban"'s message of "Mon, 29 Nov 2010 10:03:31 +0100")



Sébastien Vauban <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
writes:

> Hi Charles,
>
> Thanks a lot for taking a look at this, too...
>
> "Charles C. Berry" wrote:
>> On Sun, 28 Nov 2010, Sébastien Vauban wrote:
>>> Hi Eric and Dan,
>>>
>>> * Abstract
>>>
>>> Reporting two problems:
>>
>> Did you mean to include ":results output" in the headers?
>
> You're right that could be it. I often forget about adding that setting, even
> though it's more or less mandatory for the sh blocks -- at least, in many sh
> blocks I write...
>
>
>> When I do that in eaco of the src blocks I get what I think you were
>> expecting.
>
> I still don't. See below.
>
>
>>> 1. parsing problem of unescaped text from a shell block
>>> 2. end marker repeated upon execution of elisp block
>>>
>>> Note that I added the RESULT thing in my default headers.
>>>
>>> * Data
>>>
>>> Let's say I want to grep trough arbitrary text, such as:
>>>
>>> #+results:a-couple-of-lines
>>> : He said "I'll do it"
>>> : but that cannot be echo'ed!
>>>
>>> ... or to let it scanned by AWK for post-processing (like generating some
>>> DOT representation).
>>>
>>> But, first, as errors are popping up, let's say I can just output it as is.
>>>
>>> * Shell code
>>>
>>> #+begin_src sh :var data=a-couple-of-lines :exports both
>>> echo "$data"
>>> #+end_src
>>>
>>> #+results:
>>> #+BEGIN_RESULT
>>> #+END_RESULT
>>
>> #+begin_src sh :results output :var data=a-couple-of-lines :exports both
>> echo "$data"
>> #+end_src
>>
>> #+results:
>> : He said "I'll do it"
>> : but that cannot be echo'ed!
>
> It does not work for me. With the above, I (still) get:
>
> #+results:
> #+BEGIN_RESULT
> #+END_RESULT
>
>
> for results, and, in the *Org-Babel Error Output*:
>
> sh: line 3: unexpected EOF while looking for matching `''
> sh: line 7: syntax error: unexpected end of file

Hi Seb,

Just to say that these blocks with embedded quotes are outputting OK for
me on linux, but I do see the second bug you mention (repeatedly adding
new lines on each execution). I'm guessing that the first one is a
difference in shell quoting behaviour between out operating systems.

Dan

>
>
>>> The data is impossible (*for me*, as is) to print out from a shell code.
>>> Though, it is in Emacs-Lisp... without any change.
>>>
>>> Note that it's the second *single quote* only that's causing a problem, not
>>> the first one...
>>>
>>> * Emacs-Lisp code
>>>
>>> Executing this:
>>>
>>> #+begin_src emacs-lisp :var data=a-couple-of-lines :exports both
>>> (prin1-to-string data)
>>> #+end_src
>>>
>>> #+results:
>>> #+BEGIN_RESULT
>>> #+begin_example
>>> "He said \"I'll do it\"
>>> but that cannot be echoed!"
>>> #+END_RESULT#+end_example
>>> #+end_example
>>> #+end_example
>>> #+end_example
>>> #+end_example
>>> #+end_example
>>> #+end_example
>>> #+end_example
>>> #+end_example
>>>
>>> works, but the *end marker is repeated* as long as we re-execute the block.
>>
>> #+begin_src emacs-lisp results output :var data=a-couple-of-lines :exports both
>> (prin1-to-string data)
>> #+end_src
>>
>> #+results:
>> : "He said \"I'll do it\"
>> : but that cannot be echo'ed!"
>
> With or without the ":results output" (BTW, notice you've forgotten the colon
> in front of results), the result is the same. But, if you evaluate the block
> multiple times, in my case, the end marker (end_example) is still repeated...
>
> Best regards,
>   Seb

  parent reply	other threads:[~2010-11-29 19:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28 20:04 [Babel] Reporting 2 problems of code execution Sébastien Vauban
2010-11-29  4:34 ` Charles C. Berry
2010-11-29  9:03   ` Sébastien Vauban
2010-11-29 16:47     ` Charles C. Berry
2010-11-29 19:49     ` Dan Davison [this message]
2010-11-30  2:03     ` Eric Schulte
2010-12-02  9:35       ` Sébastien Vauban
2010-12-02 19:40         ` Eric Schulte
2010-12-02 19:58           ` Sébastien Vauban
2010-12-05 15:39             ` Eric Schulte

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=87fwujoqps.fsf@gmail.com \
    --to=dandavison7@gmail.com \
    --cc=public-emacs-orgmode-mXXj517/zsQ@plane.gmane.org \
    --cc=public-wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@plane.gmane.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).