emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [Orgmode] Re: [babel] Executing sh-code


From: Eric Schulte
Subject: Re: [Orgmode] Re: [babel] Executing sh-code
Date: Wed, 02 Dec 2009 12:09:14 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (darwin)

Hi Sébastien,

Sébastien Vauban <address@hidden> 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 <address@hidden> 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




reply via email to

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