Re: Emacs 21.3.50.1 (CVS sources) tex-mode bug

[Chip Coldwell]

I discovered that the sub shell will prompt correctly if invoked as an
interactive shell.  I wonder if Apple has been tinkering with how
bash(1) behaves (or perhaps someone at FSF?).  I suppose it is
arguably the right thing to do (i.e. not to prompt if not
interactive).  Here's a tiny patch that fixes my problem (although it
could create problems for others):

--- emacs/lisp/textmodes/tex-mode.el.~1.153.~   Sat Dec 11 17:00:38 2004
+++ emacs/lisp/textmodes/tex-mode.el    Sun Jan 16 13:59:50 2005
@@ -1495,7 +1495,8 @@
       (make-comint
        "tex-shell"
        (or tex-shell-file-name (getenv "ESHELL") shell-file-name)
-       nil)
+       nil
+       "-i")
     (let ((proc (get-process "tex-shell")))
       (set-process-sentinel proc 'tex-shell-sentinel)
       (set-process-query-on-exit-flag proc nil)

Chip

--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"


On Sun, 16 Jan 2005, Chip Coldwell wrote:

> I realize that I should expect problems if I choose to live on the
> bleeding edge, but I figure I might as well report this problem just
> in case the developers aren't already aware of it.
>
> The problem is with Emacs 21.3.50.1 that I checked out from CVS
> sources and compiled using the emacs/mac/make-package shell script on
> the Macintosh OS X (10.3.7).  If I am editing in tex-mode and I run
> the function 'tex-file' (by default bound to C-c C-f) emacs goes into
> an infinite loop.  The loop is in the function tex-mode.el:tex-start-shell
>
> (defun tex-start-shell ()
>  (with-current-buffer
>      (make-comint
>       "tex-shell"
>       (or tex-shell-file-name (getenv "ESHELL") shell-file-name)
>       nil)
>    (let ((proc (get-process "tex-shell")))
>      (set-process-sentinel proc 'tex-shell-sentinel)
>      (set-process-query-on-exit-flag proc nil)
>      (tex-shell)
>      (while (zerop (buffer-size))
>         (sleep-for 1)))))
>
> The function creates a shell using "make-comint", then waits for the
> shell to start in the loop at the bottom.  Presumably, when the shell
> has started, it will issue a prompt and the (buffer-size) procedure
> will return non-zero and break out of the loop.  The problem is that
> it never does.
>
> I tried the following trivial program
>
> (setq subshell (make-comint "subshell" "/bin/bash"))
> (switch-to-buffer subshell)
>
> And it does indeed create a subshell in a buffer, but the shell never
> issues a prompt string.  Setting the PS1 environment variable has no
> effect in this buffer, for reasons I haven't figured out yet.
>
> Chip