GNU screen tab gets renamed whenever I type a command

command linegnu-screenwindow title

When I use gnu screen, in other tabs, I ssh into other machines, rename the tab accordingly, and do work normally. The tab name sticks.

In a fresh tab, which is just a terminal on the original machine, whenever I type any command, the tab gets renamed to the current working directory.

Example:

/////////// here's how everything looks beforehand

    [me@mac ~]$
    [ me ][0*$ me@mac:~  1-$ web01  2$ dev03

////////// setting the tab name

    [me@mac ~]$ 
    Set window's title to: test
    [ me ][0*$ test  1-$ web01 clone  2$ dev03 clone

//////// typing a command: pwd

    [me@mac ~]$ pwd
    /home/me
    [me@mac ~]$
    [ me ][0*$ me@mac:~  1-$ web01 clone  2$ dev03 clone

and the tab is renamed back to the current working dir. This doesn't happen in any tab where I'm ssh'd into another machine. So I thought this might be an issue of my personal settings, but there doesn't seem to be anything in my .bashrc, .bash_profile or .screenrc files that has to do with titles.

Best Answer

Your shell configuration is setting the terminal title to the command that's currently running. It's a fairly common configuration. Since it's done by the shell, it isn't done if the shell is running on another machine with a different shell configuration. The escape sequence to set the Screen window title is ␛kTITLE␛\ where is the escape character (byte value 27).

In bash, look for code that emits this escape sequence. The escape character is probably represented as \e or \033. The code could be in the prompt (PS1) or in the command that's executed before displaying a new prompt after running a command (PROMPT_COMMAND). Check their values (taking care not to emit the escape sequences to the terminal in case they contain a literal escape character):

printf 'PS1=%s\nPROMPT_COMMAND=%s\n' "$PS1" "$PROMPT_COMMAND" | cat -v

It's also possible but less common to emit this escape sequence before running a command, via the DEBUG trap:

trap -p DEBUG

These variables (or the trap) would have to be set in the bash configuration, either yours or system-wide: normally ~/.bashrc, and /etc/bash.bashrc on some systems, but also possibly ~/.bash_profile, ~/.profile, /etc/profile or ~/.bash_login, or a file included by one of these. You can narrow it down by running a new shell with fewer settings:

env -i bash                  # no environment variables or per-user settings
env -i HOME="$HOME" bash     # no environment variables, normal interactive shell
env -i HOME="$HOME" bash -l  # no environment variables, login shell
HOME=/none bash              # skips your per-user settings

A comparison on which of those exhibits the problem will tell you whether the settings come from your settngs or system-wide ones, and whether they're from .bashrc (read by interactive shells) or from a login-time file (.profile, etc.).