The "-title" command line parameter for xterm and/or gnome-terminal does
not work. The title provided does appear momentarily on the new window,
but is quickly replaced with "userid@machine dirname". The title is
displayed correctly when one exports "TERM=vt220", but that is the only
terminal type I found that it worked for. The same bug exists for both "-
t" and "-title".

There is no PROMPT_COMMAND environment variable set on my system to conflict
with the -title parameter. This IS a bug. The -title should set the title bar
as stated in the man pages. As it did in past releases.
McNaul

I agree with Dan. I have scripts that put specific titles on specific xterms
running specific programs which I use in my work. Now they are all overidden
with the 'user@hostname pwd' and I cannot distinguish them at a glance on the
KDE taskbar, because now they all show the same user name and part of the
hostname.
It is all very well to add a new option and environment variable, but the
DEFAULT BEHAVIOR when the variable is not set (which it isn't) SHOULD NOT
CHANGE. I do not know where to find documentation on this variable or how to set
it to get the old behavior back, and I SHOULDN'T HAVE TO. Meanwhile, my work
patterns are disrupted and my productivity is decreased....

I just reproduced this and it *is* extremely annoying, I agree.
I tracked the problem down to /etc/bashrc, it contains code:
if [ "$PS1" ]; then
if [ -x /usr/bin/tput ]; then
if [ "x`tput kbs`" != "x" ]; then # We can't do this with "dumb" terminal
stty erase `tput kbs`
fi
fi
case $TERM in
xterm*)
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'
;;
*)
;;
esac
This is totally broken, and should not be forced upon a user. This code
needs to be removed, moved to the skeleton files so a user can disable it
if they want, or implemented in another way. I recommend doing away with
it myself, but that decision is ultimately up to the bash package
maintainer. Changing packages..

Bero, can you look into this and see if there is an obvious way to fix it?
For now the obvious workaround is editing ~/.bashrc and stopping it from
sourcing /etc/bashrc
I'm not sure how you'd go about detecting wether or not xterm has been
given a title argument. If it cannot be fixed easily, the best way is
likely to change the default behaviour of xterm to display
user@host:[$|#]<cwd>
Let me know if you think this is best, and I'll hack on xterm.

I just looked into the xterm source and while I could hack this
into xterm for the default window title, once it is set, it will stay
like that so it isn't very useful because the path does not bet updated
when you cd.
So.. I think the code should be moved to the .bashrc skeleton files
instead of /etc/bashrc, and logic put in to determine if xterm is being
called with the title arg.
I'm going to go hack for a bit.

I played around with it a bit and here is some crud I came up with. As
is, it does not quite work, but is close, however it would only work with
xterm, and other similar apps that take -title, -T as args to set the title.
# Was xterm given the -title or -T args?
cat /proc/$PPID/cmdline |grep "\-\(title\|T\)" >& /dev/null
[ $? ] || {
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'
}
It might be possible to tweak it into working, but it is nothing more than a hack.

bashrc lives in setup these days...
The current version has some hooks you might be interested in, though:
If you create
/etc/sysconfig/bash-prompt-xterm
and
/etc/sysconfig/bash-prompt-default
they will override the default PROMPT_COMMAND.