14

I'm doing some programming on a colleague's machine. He has a version of emacs (23.1.1) I haven't used before. My problem is that when I go to shell-mode, my bash prompt looks like this:

^[]0;jay@socrates:~^G[jay@socrates]$ 

I have PS1 set to '[\u@\h]\$ ' in my .bashrc. It's supposed to look like this:

[jay@socrates]$

This is how it looks in a regular shell. I've also checked that PS1 is set to the correct value in the emacs shell, so now I'm out of ideas. How can I get my prompt to look the way I want?

I've seen some suggestions to use term or eshell instead of shell. term has the same prompt problem as above, and eshell completely ignores my PS1 so that doesn't really help.

4 Answers 4

14

Your shell is trying to set the XTerm's (or other console) title/header. There are a number of ways this might be being done.

First make sure the PS1 is really what you think it is

echo $PS1 | less -E

That will tell you if there are control characters in the prompt, less will make them look funny. Assuming your prompt is exactly as you say, then it is probably the PROMPT_COMMAND environment variable. You can look at that the same way...

echo $PROMPT_COMMAND | less -E

If the prompt command is the problem, then you can just unset it. In either case, these variables are being set up somewhere, and should not be set to update the XTerm header, if you're not in an XTerm!

You can look in the "standard" bashrc (/etc/bashrc). You should see code that checks for an iteractive shell (is PS1 set), and then checks for xterm (looking at $TERM variable), and does something different there than for other terminal types.

I suspect somewhere in the bash initialization is a hard-coded setup, which should only be done on xterm-compatible console programs. Read man bash to find a total list of files you can look for and through.

If all of the above fails, try

printenv | less

And see if you can find something suspicious in there, and then track down where it is being set. Post it here if you can't work it out.

2
  • 1
    PROMPT_COMMAND was the problem. I'm not sure where it's getting set, but I added a line to my ~/.bashrc to unset it, and that works. Thanks!
    – Jay Conrod
    Aug 31, 2009 at 21:01
  • PROMPT_COMMAND was killing me as well. I'm using MobaXTerm and it has a particularly complicated bash prompt that was a combination of PS1 and PROMPT_COMMAND. Nov 8, 2016 at 2:44
5

I came across exact same problem and it is due to PROMPT_COMMAND. I like the xterm title. So I added following line in ~/.emacs_bash

export PROMPT_COMMAND=""
2

It may be something to do with the terminal type of the emacs shell vs your regular shell. Check what the TERM environment variable is set to in both shells. If they are different then you should be able to change the emacs shell terminal type or use a different PS1 definition for the emacs terminal type in .bashrc.

You could also try M-x ansi-term (and ansi-color-for-comint-mode-on if you have colour prompts).

1
  • 1
    ansi-color-for-comint-mode-on helped me!
    – User1
    Oct 27, 2009 at 19:46
1

This was answered very well on the stackoverflow site. by Daniel Poe.

Here's his answer.

You can use AnsiTerm which does support colors or you can enable AnsiColor for the normal shell:

(autoload 'ansi-color-for-comint-mode-on "ansi-color" nil t)
(add-hook 'shell-mode-hook 'ansi-color-for-comint-mode-on)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .