help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: 2 emacs shell questions


From: Pascal J. Bourguignon
Subject: Re: 2 emacs shell questions
Date: Wed, 08 Dec 2010 15:34:22 -0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

kj <no.email@please.post> writes:

> Two emacs shell questions.  (By "emacs shell" I mean the one that
> runs when one executes M-x shell.)
>
> 1. When I run some programs within this shell (e.g. the python
>    interactive interpreter), I get several repetitions of the error
>    message
>
> No entry for terminal type "emacs";
> using dumb terminal settings.
>
>    Where is this "entry" being searched for, and what do I need to
>    do so that one for terminal type "emacs" is found?

Good question.

This comes from the environment variable TERM.
In M-x shell RET this environment variable is set to "emacs".

Programs who need to issue terminal specific control codes (notably via
the ncurses and readline libraries, including others), will try to find
an entry by that name in the termcap(5) [old] or terminfo(5) [new]
databases.  These libraries will fallback to the "dumb" terminal when
they cannot find the $TERM in these databases (either because the
setting of TERM is incorrect, or because these databases are not
installed).

A dumb terminal has very little capabilities, basically it only
understands CR and LF.


M-x shell RET indeed doesn't interpreter any control code beyond those
two.  However, it is based on comint, so you could activate the filter
to interpret ANSI color control codes: M-x ansi-color-for-comint-mode-on
RET but this won't help for programs needing to move the cursor.




> 2. For some reason, when in the emacs shell, a set ignoreeof option
>    in zsh is being disregarded.  As a result pressing C-d when
>    point is at the end of the buffer causes the emacs shell to
>    terminate (i.e. the EOF sent to the subprocess is *not* being
>    ignored, contrary to what the set ignoreeof option specifies).

By default, C-d is bound to comint-delchar-or-maybe-eof which, I guess,
"sends an EOF" when there remains no character to delete.  I think that
it doesn't send C-d, it just closes the communication channel.



In any case, you could rebind it to a more inoccuous delete-char:

(defun my-shell-mode-meat ()
   (interactive)
   (local-set-key (KBD "C-d") 'delete-char))

(add-hook 'shell-mode-hook 'my-shell-mode-meat)



>    Even more strangely, this does not happen with bash (setting
>    its ignoreeof option produces the expected behavior).  Also,
>    zsh's ignoreeof works fine when I run it on a regular terminal
>    (as opposed to the emacs shell).  So there problem seems to be
>    specific to the combination of zsh and emacs shell, but I can't
>    tell whether the problem lies with Emacs or with zsh.  Any
>    suggestions on how to troubleshoot this further would be
>    appreciated.

This is strange indeed.  It would seem to invalidate my theory.  Time
for you to have a look at the sources.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.


reply via email to

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