From: "Eric Schulte" <schulte.eric@gmail.com>
To: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: [babel] Executing sh-code
Date: Wed, 02 Dec 2009 12:09:14 -0700 [thread overview]
Message-ID: <m2ocmhxkf9.fsf@gmail.com> (raw)
In-Reply-To: <87iqcr9fo3.fsf@mundaneum.com> ("Sébastien Vauban"'s message of "Tue, 01 Dec 2009 11:01:16 +0100")
Hi Sébastien,
Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
> Hi Eric,
>
> FYI, I just re-did a git pull && make clean && make, before writing this post
> (5 min ago). I also launched a new Emacs.
>
> "Eric Schulte" wrote:
>> Sébastien Vauban <wxhgmqzgwmuf@spammotel.com> writes:
>>>
>>> Let's assume the following Org file:
>>>
>>> #+begin_src sh :session "ecm"
>>> cd ~/Personal
>>> #+end_src
>>>
>>> #+begin_src sh :session "ecm"
>>> ls *.org
>>> #+end_src
>>>
>>> I C-c C-c the first snippet. Nothing special, except it doesn't hang anymore.
>>> So, it already looks much better.
>>>
>>> Second snippet. C-c C-c. There, it still hangs ;-((
>>>
>>> Though, C-x C-b shows me the contents of the "ecm" buffer:
>>>
>>> cd ~/Personal
>>>
>>> ~ % ~/Personal % ls *.org
>>> echo 'org_babel_sh_eoe'
>>> Bookmarks.org Scorpios.org Tickler.org Voice-over-IP.org*
>>> Home.org* Succession.org Using-startx-for-Remote-Display.org refile.org
>>> ~/Personal % org_babel_sh_eoe
~/Personal %
>
> I am still puzzled by the order the commands are mixed with their output:
>
> 1. ls command
> 2. echo command
> 3. ls output
> 4. echo output
>
> It's like if everything was sent at once, instead of waiting for the prompt to
> appear.
>
Yes, there is no easy way that I know of to wait until a command returns
w/o adding some sort of sleep command or complicated filter, so all
commands are inserted before the shell has a chance to respond.
exactly
>
> Would I write see in Expect (I love it), I would write something like:
>
sadly there is no comparable elisp library that I am aware of. Luckily
it shouldn't matter as the commands are still input to the shell in the
same order, and the output is still collected directly form the shell
with a filter.
>
> 1. expect prompt
> 2. send ls command
> 3. expect result followed by prompt
> 4. send echo command
> 5. expect result followed by prompt
>
> But, maybe, my observation has nothing to do with my problem...
>
Correct, I don't believe this is related to the problem.
> >
>> So the fix here is to fix the value of the `comint-prompt-regexp'
>> variable in your shell. Org-babel uses this variable to digest output
>> from the shell. I have mine set with the following
>>
>> (defun schulte/set-shell-prompt-regexp ()
>> (setq comint-prompt-regexp "^\(.+\)"))
>> (add-hook 'shell-mode-hook 'schulte/set-shell-prompt-regexp)
>
> I've put that in my .emacs file, as you can see (when asking for its value in
> the shell buffer):
>
I'm sorry I wasn't clear in my earlier email. You will need to craft
your own regexp to replace "^\(.+\)" in the above code. This is because
you will need to match your own prompt as it appears in your *shell*
buffers locally. This would be the product of your personal .bashrc or
.zshrc prompt configuration. The example I pasted above matches my own
prompt which has a non-standard
( ~ )
style.
>
>> You'll have to change the regexp ("^\(.+\)" in my example) to match your
>> prompt.
>
> Nope. Because I'm using your prompt, as you can see in the above shell
> session.
>
Nope, I use a different prompt. To match a prompt like what you have
above you'd want to use something like closer to the default value of
"^[^#$%>\n]*[#$%>] *". Sorry for the confusion here.
>> on a related topic:
>>
>> I've also noticed that org-babel has difficulty digesting shell output
>> when it is ansi-colorized. I'm not sure what the best fix here would
>> be. We could probably start piping all org-babel session results
>> through something like `ansi-color-filter-region' but that feels a
>> little bit too heavy. I'd be interested to hear other peoples
>> thoughts/suggestions.
>
> Good you talk of that. Of course, I was using color in my prompt (but not
> anymore, see above), but I was coloring ls output as well...
>
> Disabled yesterday...
>
> # alias ls="ls --color=yes --classify" # `--color=auto' tells ls to use color
> # # iff output is a tty
>
> Though, even while I'm using your prompt definition, your prompt regexp
> definition, bash as shell, and no color in the ls command, I still have the
> same problem: "Emacs" hangs when C-c C-c on the `ls *.org' code block.
>
> Not sure to understand what I can do to go further...
>
I'm not sure, a fixed prompt regexp should solve the problem. I now
believe that ansi-coloring may have been a red-herring. I *do* have
colored ls output aswell, however the following works for me without any
hang. The only difference I can see between our setups is a matching
prompt regexp.
--8<---------------cut here---------------start------------->8---
#+begin_src sh :session eric
cd ~/Desktop/clj/
ls *.clj
#+end_src
#+results:
| "ants.clj" | "" | "concurrent.clj" | "" | "hello.clj" | "" | "spell-checker.clj" |
--8<---------------cut here---------------end--------------->8---
Hope this is helpful. Best -- Eric
>
> Best regards,
> Seb
next prev parent reply other threads:[~2009-12-02 19:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 14:22 [babel] Executing sh-code Sébastien Vauban
2009-11-27 9:15 ` Sébastien Vauban
2009-11-27 10:46 ` Eric S Fraga
2009-11-27 10:00 ` Torsten Wagner
2009-11-27 10:43 ` Sébastien Vauban
2009-11-27 19:32 ` Eric Schulte
2009-11-27 19:46 ` Dan Davison
2009-11-29 21:03 ` Sébastien Vauban
2009-11-30 15:44 ` Eric Schulte
2009-11-30 16:02 ` Nick Dokos
2009-11-30 16:16 ` Eric Schulte
2009-12-01 8:37 ` Sébastien Vauban
2009-12-01 10:01 ` Sébastien Vauban
2009-12-02 19:09 ` Eric Schulte [this message]
2009-12-04 13:25 ` Sébastien Vauban
2009-12-04 14:09 ` Sébastien Vauban
2009-12-04 17:04 ` Eric Schulte
2009-12-07 1:10 ` Torsten Wagner
2009-12-07 9:59 ` Sébastien Vauban
2009-12-04 17:03 ` Eric Schulte
2009-12-02 14:55 ` Sébastien Vauban
2009-12-02 20:16 ` Eric Schulte
2009-12-03 9:27 ` Sébastien Vauban
2009-12-03 16:06 ` 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=m2ocmhxkf9.fsf@gmail.com \
--to=schulte.eric@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=wxhgmqzgwmuf@spammotel.com \
/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).