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.


/////////// 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
    [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.

  • 2
    You have an escape sequence in your prompt that sets the window title. – Barmar Jun 9 '16 at 19:02
  • Nope, looks like that isn't the case: [alison@mac etc]$ echo $PS1 [\u@\h \W]$ – lowly_junior_sysadmin Jun 9 '16 at 20:28
  • You can't see escape sequences with echo. Look at the statement in your startup file that sets PS1. – Barmar Jun 9 '16 at 20:34
  • It seems to be set in /etc/bashrc (not in /etc/profile), but again I don't see an escape char (\e)... PS1='\h:\W \u\$ ' – lowly_junior_sysadmin Jun 9 '16 at 20:46
  • Check $PROMPT_COMMAND as well. See superuser.com/questions/79972/… – Barmar Jun 9 '16 at 20:49

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.).

  • +1. Instead of that printf, I prefer something like set | grep -E '^(PS[1-4]|PROMPT_COMMAND)=' – cas Jun 10 '16 at 2:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.