Bart's Blog

I must have recently upgraded to a new screen. My screenrc file was using the chdir directive so that the windows started inside would have a PWD I wanted them to. As soon as I tried to reconnect the screen session would die.

    screen -x
    Unable to open "screenrc"

I was able to find the bug on savannah that described the symptom quite well.

I then wrote a wrapper zsh function which fixes the problem:

    REAL_SCREEN=$(which screen)

    # convert the path passed via the -c parameter to an absolute one
    screen() {
            local max=$((${#argv}-1))
            for (( x=1 ; x<=$max ; x++ )) ; do
                    local flag="${argv[$x]}"
                    if [[ "x$flag" = "x-c" ]] ; then
                            local y=$(($x+1))
                            local word="${argv[$y]}"
                            if [[ "x${word[1]}" != 'x/' ]] ; then
                                    argv[$y]="$PWD/$word"
                            fi
                    fi
            done

            echo ${REAL_SCREEN} ${1+"$argv"}
            ${REAL_SCREEN} ${1+"$@"}
    }

forwarding ssh and X through screen

[ link: screen-with-ssh-and-x | tags: screen ssh desktop x zsh | updated: Thu, 18 Oct 2007 14:10:27 ]

I have an update to my previous article on forwarding ssh-agent through screen. I've since switched to zsh and am now forwarding the X DISPLAY environment variable through to the screen shell.

You can grab my ~/.zsh.d/S51_screen, ~/.zsh.d/S60_prompt, and ~/.screenrc or read below.

[Read More]

letting screen apps use the ssh-agent

[ link: screen-ssh-agent | tags: screen ssh | updated: Sat, 11 Aug 2007 10:57:44 ]

I have been wondering for a while how to do this... How to pass the ssh-agent variables to screen clients. After doing a google search on it I found a couple of solutions:

grabssh/fixssh - two scripts that save the ssh agent environment variables and restore them;
screen_agent - this just executes an ssh-agent that is used by the screen session;
fixx - ok, this actually fixes X forwarding not ssh-agent and is a variation on the first;

Then I came across Alexander Neumann's blog entry which is the perfect solution. He simply redefines the SSH_AUTH_SOCK variable and makes it point to a symlink that he creates when he logs in. This means that this method works when you're sshing into a machine running screen. I will just have to overwrite this symlink when screen is being launched.

So two changes; first is in .screenrc

    unsetenv SSH_AUTH_SOCK
    setenv SSH_AUTH_SOCK $HOME/.screen/ssh-auth-sock.$HOSTNAME

Second is is to define an alias that overwrites the symlink when screen is started:

    _ssh_auth_save() {
            ln -sf "$SSH_AUTH_SOCK" "$HOME/.screen/ssh-auth-sock.$HOSTNAME"
    }
    alias screen='_ssh_auth_save ; export HOSTNAME=$(hostname) ; screen'

Note, that the export of HOSTNAME may be unnecessary for you... it depends on the shell.

**Update: see my later article on how to use screen with ssh and X forwarding.

fixing your terminal

[ link: stty-save | tags: unix screen | updated: Sat, 02 Sep 2006 14:06:12 ]

I sometimes get into an odd state in screen. I am not sure what causes it, but it usually happens after I ctrl-C out of a console tool that wanted to do something odd with termcap. In this odd state the terminal no longer responds to the default control characters, like ctrl-H for erase.

Usually running reset does the trick and restores the terminal configuration. Well in screen, I found, this does not always work. I googled a bit and found a pretty neat article titled Unix Tip: Using stty to Your Advantage, which shows how to save the current state of the terminal and restore it later.

To store the configuration:

    $ echo stty `stty -g` > restore-tty
    $ chmod 755 restore-tty

and when things mess up...

    $ ./restore-tty

It fixes my problems.

Bart's Blog

Now viewing: /tag/screen

Links

Search

Bookmarks

Tags

Posts

...