screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Setting window title in ssh'ed host


From: Trent W. Buck
Subject: Re: Setting window title in ssh'ed host
Date: Tue, 15 Jul 2008 09:46:22 +1000
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Jul 12, 2008 at 03:10:00AM +0300, Gokdeniz Karadag wrote:
> This is more like a story, I am trying to automatically set "GNU
> screen window title" equal to the hostname that is connected by ssh.

In my .profile, which exists on all my machines and is evaluated for
all interactive logins (i.e. "ssh fooserv", but not "ssh fooserv
pwd"), I have

    type uname >/dev/null 2>&1 &&
    test -n "${HOSTNAME:=`uname -n`}" &&
    case "$TERM" in
        screen*) printf %bk%s%b%b \\033 "${HOSTNAME%%.*}" \\033 \\0134;;
    esac

Note that the "type" builtin isn't portable, if you use .bash_profile
you can instead just use

    case "$TERM" in
        screen*) printf %bk%s%b%b \\033 "${HOSTNAME%%.*}" \\033 \\0134;;
    esac

I use this in preference to doing it inside screen because I couldn't
work out how to have an "alias" or "function" in screen such that

    C-a x fooserv RET

would expand to something like

    C-a :screen -t fooserv ssh fooserv

If anyone knows how to do that, I'd prefer it (since customer machines
don't have my .profile installed).

> Sometimes I logout of the connected machine and connect to another.
> I don't want to set title each time I do this.  If there is no
> screen in the way, the following bash variable shows the hostname in
> xterm title.  PROMPT_COMMAND='echo -ne "\033]0;${HOSTNAME}\007"'

Oh, have a screen window with a shell, and you run "ssh fooserv" in
the shell.  I *think* my approach still works in that case.

> If I use this, and change %t->%h in hardstatus string, the hostname
> shows in the "currently selected window only", but not the
> others. As there is no equivalent of "-w" "+w" for xterm title(which
> is an actual "hard" status), this path was blocked.

I didn't understand any of that paragraph.

> To ensure that only ssh sessions within a GNU screen get the "title
> setter prompt command", environment variables are useful, I can use
> the TERM variable, but in stable debian, the default TERM=screen
> breaks vim editor, it goes crazy when you press home, or pageup
> buttons.  Using TERM=xterm fixes this, so I cannot check for TERM
> being equal to "screen".

Then you should fix vim, not train Screen to work with the wrong
settings.  Does vim work correctly (with TERM screen) if you tell it
not to evaluate your .vimrc and such?  If so, then the problem is with
your .vimrc, not with vim itself.

> I put "setenv INSCREEN yes" into .screenrc, and in the target shell,
> I set PROMPT_COMMAND if this variable is set, but then,(surprise,
> surprise!) ssh would not pass variables to target machine.  At
> least, does not pass unless you use AcceptEnv in ssh server config,
> but I don't want to use it for security reasons.

You need to configure ssh to do so with the SendEnv directive in
~/.ssh/config.  See ssh_config(5) manpage.  Dunno about AcceptEnv, I
guess you've tried it more than I have.

> Ok, maybe not because of security, but changing "ssh server
> configuration" for only setting screen's window title seems absurd.

I agree.

> A solution that I imagined was to extend the "stuff" line; it does the ssh
> connection, then puts the PROMPT_COMMAND to set GNU screen window title.
> escaping this correctly was a chore, but I managed after some experimentation.
> stuff "ssh hostname\015export PROMPT_COMMAND='echo -n -e 
> "\\033k\${HOSTNAME}\\033\\\\\"'\015"

Instead of using :stuff, why not just set the title when you create
the screen window, running ssh instead of the default shell?

C-a :screen -t fooserv ssh fooserv

> But of course, the connections made after these do not set the title.

In the approach I propose, each subsequent ssh would get a fresh
window, so this would work.

> [[ rant: Why, why, why this great software gets the most generic
> name of "screen" ?

I agree.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]