I mentioned [earlier]{ubifs-on-sheeva} that I will be giving a talk at Flourish Conf next month. While preparing for the talk I decided to I wanted to share my terminal with the participants of the Workshop via telnet. The more popular alternative would be to use screen built in sharing, or maybe vnc, which would require more memory and CPU overhead… and additional accounts using the former method. I only have a SheevaPlug to work with, so I am trying to be as conservative as possible.

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:

I have an update to my [previous article]{screen-ssh-agent} on forwarding [ssh-agent]{tag/ssh} through [screen]{tag/screen}. I’ve since switched to [zsh]{tag/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.

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.

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.