Hi Sébastien,
Sébastien Vauban <wxhgmqzgw...@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 <wxhgmqzgw...@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
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
