bug#5255: 23.1.90; Wrong prompt in term

bug#5255: 23.1.90; Wrong prompt in term

[Fabian Ezequiel Gallina]

In emacs 23.1 when I use M-x term the prompt is rendered correctly to
whatever is defined on the PS1 environment variable. But in 23.1.90.1 it
prompts whatever is defined in the PS1 but also before that, it prompts
0;<user>@<host>:<location>.

The steps to reproduce it are quite simple:

emacs -Q
M-x term

The prompt is rendered like this:

0;fgallina@cuca:~/Builds/emacs[fgallina@cuca emacs]$

Since my PS1 is set to

PS1='[\u@\h \W]\$ '

the expected result is:

[fgallina@cuca emacs]$

In GNU Emacs 23.1.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.5)
 of 2009-12-20 on cuca
Windowing system distributor `The X.Org Foundation', version 11.0.10703901
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: es_AR.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> M-x t e r m <return>
<return> l s <return> M-c <backspace> M-x <backspace>
C-c b <return> M-x r e m p o <backspace> <backspace>
<backspace> p o <tab> r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug help-mode easymenu view term
disp-table ehelp electric ring tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process dbusbind
system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs)

bug#5255: 23.1.90; Wrong prompt in term

[Dan Nicolaescu]

Fabian Ezequiel Gallina <galli.87@gmail.com> writes:

  > In emacs 23.1 when I use M-x term the prompt is rendered correctly to
  > whatever is defined on the PS1 environment variable. But in 23.1.90.1 it
  > prompts whatever is defined in the PS1 but also before that, it prompts
  > 0;<user>@<host>:<location>.
  > 
  > The steps to reproduce it are quite simple:
  > 
  > emacs -Q
  > M-x term
  > 
  > The prompt is rendered like this:
  > 
  > 0;fgallina@cuca:~/Builds/emacs[fgallina@cuca emacs]$
  > 
  > Since my PS1 is set to
  > 
  > PS1='[\u@\h \W]\$ '
  > 
  > the expected result is:
  > 
  > [fgallina@cuca emacs]$

I can't reproduce this.
Are you sure that your prompt is set to what you show there?  Maybe the
system default sets it to something else?

bug#5255: 23.1.90; Wrong prompt in term

[Fabian Ezequiel Gallina]

2009/12/22 Dan Nicolaescu <dann@ics.uci.edu>:
> Fabian Ezequiel Gallina <galli.87@gmail.com> writes:
>
>  > In emacs 23.1 when I use M-x term the prompt is rendered correctly to
>  > whatever is defined on the PS1 environment variable. But in 23.1.90.1 it
>  > prompts whatever is defined in the PS1 but also before that, it prompts
>  > 0;<user>@<host>:<location>.
>  >
>  > The steps to reproduce it are quite simple:
>  >
>  > emacs -Q
>  > M-x term
>  >
>  > The prompt is rendered like this:
>  >
>  > 0;fgallina@cuca:~/Builds/emacs[fgallina@cuca emacs]$
>  >
>  > Since my PS1 is set to
>  >
>  > PS1='[\u@\h \W]\$ '
>  >
>  > the expected result is:
>  >
>  > [fgallina@cuca emacs]$
>
> I can't reproduce this.
> Are you sure that your prompt is set to what you show there?  Maybe the
> system default sets it to something else?
>

I guess I found the problem:

[fgallina@cuca lisp]$ env | grep PROMPT_COMMAND
PROMPT_COMMAND=echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"

Now the thing is that executing this in a normal terminal renders
nothing, as opposed to term. My guess would be that term is missing
the \033] escape sequence.

bug#5255: 23.1.90; Wrong prompt in term

[Dan Nicolaescu]

Fabian Ezequiel Gallina <galli.87@gmail.com> writes:

  > 2009/12/22 Dan Nicolaescu <dann@ics.uci.edu>:
  > > Fabian Ezequiel Gallina <galli.87@gmail.com> writes:
  > >
  > >  > In emacs 23.1 when I use M-x term the prompt is rendered correctly to
  > >  > whatever is defined on the PS1 environment variable. But in 23.1.90.1 it
  > >  > prompts whatever is defined in the PS1 but also before that, it prompts
  > >  > 0;<user>@<host>:<location>.
  > >  >
  > >  > The steps to reproduce it are quite simple:
  > >  >
  > >  > emacs -Q
  > >  > M-x term
  > >  >
  > >  > The prompt is rendered like this:
  > >  >
  > >  > 0;fgallina@cuca:~/Builds/emacs[fgallina@cuca emacs]$
  > >  >
  > >  > Since my PS1 is set to
  > >  >
  > >  > PS1='[\u@\h \W]\$ '
  > >  >
  > >  > the expected result is:
  > >  >
  > >  > [fgallina@cuca emacs]$
  > >
  > > I can't reproduce this.
  > > Are you sure that your prompt is set to what you show there?  Maybe the
  > > system default sets it to something else?
  > >
  > 
  > I guess I found the problem:
  > 
  > [fgallina@cuca lisp]$ env | grep PROMPT_COMMAND
  > PROMPT_COMMAND=echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"

That looks like a bad idea.
I am guessing that you are trying to set the xterm title to display the
current directory in the shell, this uses an xterm specific escape sequence.
So it should only be done for xterm.

But you should not need to use PROMPT_COMMAND to do this, it can be done
by just setting the prompt, search the web for something like: "bash
prompt xterm title"

  > Now the thing is that executing this in a normal terminal renders
  > nothing, as opposed to term. My guess would be that term is missing
  > the \033] escape sequence.

It's actually \033];STUFF\007.

bug#5255: 23.1.90; Wrong prompt in term

[Fabian Ezequiel Gallina]

2009/12/22 Dan Nicolaescu <dann@ics.uci.edu>:
>  >
>  > I guess I found the problem:
>  >
>  > [fgallina@cuca lisp]$ env | grep PROMPT_COMMAND
>  > PROMPT_COMMAND=echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"
>
> That looks like a bad idea.
> I am guessing that you are trying to set the xterm title to display the
> current directory in the shell, this uses an xterm specific escape sequence.
> So it should only be done for xterm.
>

Yes, it is used just for that, I found this which explains the thing:
http://www.faqs.org/docs/Linux-mini/Xterm-Title.html#ss3.1

> But you should not need to use PROMPT_COMMAND to do this, it can be done
> by just setting the prompt, search the web for something like: "bash
> prompt xterm title"
>

I didn't set up it myself, I guess xterm sets this automatically.

>  > Now the thing is that executing this in a normal terminal renders
>  > nothing, as opposed to term. My guess would be that term is missing
>  > the \033] escape sequence.
>
> It's actually \033];STUFF\007.
>

Oh yes, actually that is not being taken into account and I guess it
should, at least that's what happens in emacs 23.1.

bug#5255: 23.1.90; Wrong prompt in term

[Dan Nicolaescu]

Fabian Ezequiel Gallina <galli.87@gmail.com> writes:

  > 2009/12/22 Dan Nicolaescu <dann@ics.uci.edu>:
  > >  >
  > >  > I guess I found the problem:
  > >  >
  > >  > [fgallina@cuca lisp]$ env | grep PROMPT_COMMAND
  > >  > PROMPT_COMMAND=echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"
  > >
  > > That looks like a bad idea.
  > > I am guessing that you are trying to set the xterm title to display the
  > > current directory in the shell, this uses an xterm specific escape sequence.
  > > So it should only be done for xterm.
  > >
  > 
  > Yes, it is used just for that, I found this which explains the thing:
  > http://www.faqs.org/docs/Linux-mini/Xterm-Title.html#ss3.1

The explanation is not very clear, it actually shows how this can be
done by using just PS1 and not PROMPT_COMMAND...
And it's shown that is should only happen when TERM is xterm.

  > > But you should not need to use PROMPT_COMMAND to do this, it can be done
  > > by just setting the prompt, search the web for something like: "bash
  > > prompt xterm title"
  > >
  > 
  > I didn't set up it myself, I guess xterm sets this automatically.

xterm does not do things like that.
Your system does it then, and it's wrong, it should only do it if TERM
is xterm.

  > 
  > >  > Now the thing is that executing this in a normal terminal renders
  > >  > nothing, as opposed to term. My guess would be that term is missing
  > >  > the \033] escape sequence.
  > >
  > > It's actually \033];STUFF\007.
  > >
  > 
  > Oh yes, actually that is not being taken into account and I guess it
  > should, at least that's what happens in emacs 23.1.

This is an xterm specific escape sequence, most likely due to a bad
setup, you'll get the same problem if you use a vt100 terminal for
example.  
So this is not a term.el problem.

bug#5255: 23.1.90; Wrong prompt in term

[Fabian Ezequiel Gallina]

2009/12/22 Dan Nicolaescu <dann@ics.uci.edu>:
>
> This is an xterm specific escape sequence, most likely due to a bad
> setup, you'll get the same problem if you use a vt100 terminal for
> example.
> So this is not a term.el problem.
>

Thanks for the explanation, I just added this to my .bashrc and
everything started to work fine again:

if [[ $TERM =~ ^xterm ]];
then
	TERM=xterm-256color
	PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"'
else
	PROMPT_COMMAND=""
fi

However what really surprises me is that emacs 23.1 didn't got the
prompt wrong with my old PROMPT_COMMAND.


Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com

bug#5255: 23.1.90; Wrong prompt in term

[Stefan Monnier]

> However what really surprises me is that emacs 23.1 didn't got the
> prompt wrong with my old PROMPT_COMMAND.

Odd, indeed.  If you could try and investigate further to try and figue
out what caused the change, it would be helpful.


        Stefan

bug#5255: marked as done (23.1.90; Wrong prompt in term)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

Your message dated Mon, 28 Dec 2009 11:28:21 -0800 (PST)
with message-id <200912281928.nBSJSLSU012776@godzilla.ics.uci.edu>
and subject line Re: bug#5255: 23.1.90; Wrong prompt in term
has caused the Emacs bug report #5255,
regarding 23.1.90; Wrong prompt in term
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact bug-gnu-emacs@gnu.org
immediately.)


-- 
5255: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5255
Emacs Bug Tracking System
Contact bug-gnu-emacs@gnu.org with problems

[-- Attachment #2: Type: message/rfc822, Size: 6471 bytes --]

From: Fabian Ezequiel Gallina <galli.87@gmail.com>
To: emacs-pretest-bug@gnu.org
Subject: 23.1.90; Wrong prompt in term
Date: Sun, 20 Dec 2009 23:44:21 -0300
Message-ID: <9de1a5ef0912201844r45f00f26s82560a57251524d0@mail.gmail.com>

In emacs 23.1 when I use M-x term the prompt is rendered correctly to
whatever is defined on the PS1 environment variable. But in 23.1.90.1 it
prompts whatever is defined in the PS1 but also before that, it prompts
0;<user>@<host>:<location>.

The steps to reproduce it are quite simple:

emacs -Q
M-x term

The prompt is rendered like this:

0;fgallina@cuca:~/Builds/emacs[fgallina@cuca emacs]$

Since my PS1 is set to

PS1='[\u@\h \W]\$ '

the expected result is:

[fgallina@cuca emacs]$

In GNU Emacs 23.1.90.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.5)
 of 2009-12-20 on cuca
Windowing system distributor `The X.Org Foundation', version 11.0.10703901
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: es_AR.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> M-x t e r m <return>
<return> l s <return> M-c <backspace> M-x <backspace>
C-c b <return> M-x r e m p o <backspace> <backspace>
<backspace> p o <tab> r <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug help-mode easymenu view term
disp-table ehelp electric ring tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process dbusbind
system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs)



[-- Attachment #3: Type: message/rfc822, Size: 3866 bytes --]

From: Dan Nicolaescu <dann@ics.uci.edu>
To: Fabian Ezequiel Gallina <galli.87@gmail.com>
Cc: 5255-done@debbugs.gnu.org
Subject: Re: bug#5255: 23.1.90; Wrong prompt in term
Date: Mon, 28 Dec 2009 11:28:21 -0800 (PST)
Message-ID: <200912281928.nBSJSLSU012776@godzilla.ics.uci.edu>

Fabian Ezequiel Gallina <galli.87@gmail.com> writes:

  > 2009/12/22 Dan Nicolaescu <dann@ics.uci.edu>:
  > >
  > > This is an xterm specific escape sequence, most likely due to a bad
  > > setup, you'll get the same problem if you use a vt100 terminal for
  > > example.
  > > So this is not a term.el problem.
  > >
  > 
  > Thanks for the explanation, I just added this to my .bashrc and
  > everything started to work fine again:

I am closing this bug, it's not a bug in term.el

  > if [[ $TERM =~ ^xterm ]];
  > then
  > 	TERM=xterm-256color

Changing the value of TERM is a bad idea, unless you know exactly what
you are doing.

  > 	PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"'

Using PROMPT_COMMAND is not a good idea, the same thing can be done with
just setting the prompt.