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

[Sébastien Vauban]

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.

Would I write see in Expect (I love it), I would write something like:

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


> 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):

--8<---------------cut here---------------start------------->8---
comint-prompt-regexp's value is "^(.+)"
Local in buffer "ecm"; global value is "^"

Documentation:
Regexp to recognize prompts in the inferior process.
Defaults to "^", the null string at BOL.

This variable is only used if the variable
`comint-use-prompt-regexp' is non-nil.

Good choices:
  Canonical Lisp: "^[^> \n]*>+:? *" (Lucid, franz, kcl, T, cscheme, oaklisp)
  Lucid Common Lisp: "^\\(>\\|\\(->\\)+\\) *"
  franz: "^\\(->\\|<[0-9]*>:\\) *"
  kcl: "^>+ *"
  shell: "^[^#$%>\n]*[#$%>] *"
  T: "^>+ *"

This is a good thing to set in mode hooks.
--8<---------------cut here---------------end--------------->8---


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


> I was unable to create your prompt locally. I find the `regexp-builder'
> function to be very handy for these situations. If you are unable to build a
> working regexp please send me a string of your prompt and I'd be happy to
> return an appropriate regexp.

N/A, if I understand you correctly, as I'm using your prompt within Emacs
shells:

--8<---------------cut here---------------start------------->8---
PS1="\w % "
--8<---------------cut here---------------end--------------->8---


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

--8<---------------cut here---------------start------------->8---
# alias ls="ls --color=yes --classify"  # `--color=auto' tells ls to use color
#                                       # iff output is a tty
--8<---------------cut here---------------end--------------->8---

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

Best regards,
  Seb

-- 
Sébastien Vauban