but the xterm title doesn’t reflect my custom text. (I’ve used two @'s to ensure I’m seeing my change). This also happens with konsole if go to Settings > Edit Current Profile > Tabs and set “Table title format” to %w (window title set by shell). According to many searches, the above sequence should work just fine.
If I unset that environment variable and directly echo the same string, no change - it still doesn’t work. Thus it doesn’t seem to be related to bash configuration (dot files).
Anyone have any ideas what’s wrong? Is this crucial feature broken in KDE 4.11.5?
Im not sure what are you trying to do with that prompt command. There are characters/strings in there that is special to the shell so it will not work, you need to escape it. Still i don’t understand what you want to achieve with this. Maybe you want PS1 instead?
Nope, PS1 is specifically for generating the command prompt. I don’t care about the command prompt here; the reason I’m setting PROMPT_COMMAND is to get the side effect of echoing the special characters needed to set the terminal title.
Not according to the web pages I read (linked above). PROMPT_COMMAND is just something run before the prompt is generated, and doesn’t itself set the prompt. By echoing special character sequences, I can change the xterm title, or should be able to, according to those pages.
Wrong. See the two links I posted in the response to the other user. They should work. They are specific sequences to change the title.
When I echo that, it moves my cursor to a higher position in the terminal window, but doesn’t affect the title.
If I execute this in my bash shell, each command starts being written on top of the previous one (it no longer scrolls) and thus becomes corrupted and unusable. I had to kill off the xterm after doing this and start another one.
When I echo that, it moves my cursor to a higher position in the terminal window, but doesn’t affect the title.
I never said that this should change the title. It was an example that escape sequences work in general.
If I execute this in my bash shell, each command starts being written on top of the previous one (it no longer scrolls) and thus becomes corrupted and unusable. I had to kill off the xterm after doing this and start another one.
You could have just set PS1 to something else. No need to kill xterm…
Apparently ppwd() gets called before the prompt is printed, but after PROMPT_COMMAND. The default function (defined in /etc/bash.bashrc) sets the window title to the standard one (“user@host: dir”), which overrides the title you set via PROMPT_COMMAND.
Personally, I consider that a misfeature. Fortunately, I use “csh” rather than “bash”, so I don’t have to put up with it.
In any case, I opened an xterm with the title that I wanted (using “-title”). Then I ran “bash” in that xterm. And, sure enough, that misfeature did its annoying thing and changed the title.
This is with opensuse 13.2. I haven’t checked 13.1, though I’m pretty sure it does the same.
What this shows is that bash is still able to emit an escape sequence that tells “xterm” to change its title. So I don’t think a feature (or misfeature) is broken.
To be a bit pedantic, neither “xterm” nor “bash” is part of KDE. So it would not be a KDE feature.
If you undefine ppwd() in ~/.bashrc or /etc/bash.bashrc.local, the -title parameter works fine as well.
Actually this is no misfeature of bash, but just the standard openSUSE setup (as mentioned, ppwd() is defined in /etc/bash.bashrc to change the window title every time the shell prints a prompt).
Oh, and actually ppwd() is called by the prompt. See “echo $PS1”…
So setting PS1 to something else will prevent the window title from being changed as well, and will make your escape sequences for changing the title work.
I probably should have used a smiley. I did not say that it was a bash misfeature. It’s a “standard openSUSE setup” misfeature. It’s probably there for “csh” too. But I do a major edit on “/etc/csh.cshrc” to remove as much of the annoying stuff as I can.
I once tried to delete “/etc/csh.cshrc” and “/etc/csh.login”, but X failed to start. Maybe I should try that again – it’s been a few years since I last tried that.
It’s probably there for “csh” too. But I do a major edit on “/etc/csh.cshrc” to remove as much of the annoying stuff as I can.
Yes. The default csh.cshrc contains this:
## Prompting and Xterm title
#
set prompt="%B%m%b %C2%# "
if ( -o /dev/$tty && -c /dev/$tty ) then
alias cwdcmd '(echo "Directory: $cwd" > /dev/$tty)'
if ( -x /usr/bin/biff ) /usr/bin/biff y
# If we're running under X11
if ( ${?DISPLAY} ) then
if ( ${?TERM} && ${?EMACS} == 0 && ${?MC_SID} == 0 && ! -r $HOME/.csh.expert ) then
if ( ${TERM} == "xterm" ) then
alias cwdcmd '(echo -n "\033]2;$USER on ${HOST}: $cwd\007\033]1;$HOST\007" > /dev/$tty)'
cd .
endif
endif
if ( -x /usr/bin/biff ) /usr/bin/biff n
set prompt="%C2%# "
endif
endif
So in csh you’d have to redefine/undefine the alias “cwdcmd”.
See also “man csh”:
The beepcmd, cwdcmd, periodic, precmd, postcmd, and jobcmd **Special
aliases** can be set, respectively, to execute commands when the shell
wants to ring the bell, when the working directory changes, every **tpe-
riod** minutes, before each prompt, before each command gets executed,
after each command gets executed, and when a job is started or is
brought into the foreground.
