Is zsh buggy in connection with screen?

Is zsh buggy in connection with screen?

[Sebastian Stein]

The following scenario:

I have screen running under X11. In screen I have different zshs open. Some
of them are currently running a vim. I detached screen for about 1 hour from
X11. After I attach it again and try to insert something in the vim, they
abort saying there was a X11 error (bad window name).

Can this be related to zsh? I don't see why this should be caused by
something else, because I have not upgraded any software package connected
to X11, vim or shell. I never had this problem using bash.

Sebastian

Re: Is zsh buggy in connection with screen?

[Vincent Lefevre]

On 2005-11-08 14:02:33 +0100, Sebastian Stein wrote:
> The following scenario:
> 
> I have screen running under X11. In screen I have different zshs open. Some
> of them are currently running a vim. I detached screen for about 1 hour from
> X11. After I attach it again and try to insert something in the vim, they
> abort saying there was a X11 error (bad window name).
> 
> Can this be related to zsh?

I don't think so, why would it be?

The problem may be due to specific environment variables or a
different configuration concerning the terminal.

> I don't see why this should be caused by something else, because I
> have not upgraded any software package connected to X11, vim or
> shell. I never had this problem using bash.

What is your terminal? xterm for instance sets environment variables
that are no longer valid in a different terminal and/or X11 session:

ENVIRONMENT
       Xterm sets several environment variables:

       DISPLAY
            is the display name, pointing to the X server (see  DISPLAY  NAMES
            in X(1)).
[...]
       WINDOWID
            is set to the X window id number of the xterm window.

This may be your problem...

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Is zsh buggy in connection with screen?

[Wayne Davison]

On Tue, Nov 08, 2005 at 03:13:17PM +0100, Vincent Lefevre wrote:
> What is your terminal? xterm for instance sets environment variables
> that are no longer valid in a different terminal and/or X11 session:

I use screen too, and have implemented some environment variable
"tunneling" to ensure that the inner shells get their environment
updated.  What I did is to write a shell script named "update_screenenv"
that writes out a set of environment-updating commands into a file named
~/.screenenv.  I then alias my normal screen-startup command (which
happens to be the alias "scr") to run this command before starting
screen:

    alias scr=' ~/bin/update_screenenv; screen -R -d -i'

Finally, I define a preexec function in my .zshrc, but only when the
TERM is "screen*", so that the inner shells source this file (my preexec
command also does other things, but I've removed them for clarity):

    case "$TERM" in
    screen*)
	function preexec {
	    . ~/.screenenv
	}
	;;
    xterm*)
	# ... etc. ...
	;;
    *)
	# ... etc. ...
	;;
    esac

Using this causes the inner zsh environments to get updated from the
outer environment that was present when screen was re-attached.

My update script looks like this (yeah, it's ugly, but it works):

    #!/bin/zsh
    cat >~/.screenenv <<EOT
    export SSH_AUTH_SOCK=$SSH_AUTH_SOCK
    EOT
    if [[ -n "$SSH_AGENT_PID" ]]; then
	export SSH_AGENT_PID=$SSH_AGENT_PID >>~/.screenenv
    else
	echo "unset SSH_AGENT_PID" >>~/.screenenv
    fi
    if [[ -n "$DISPLAY" ]]; then
	echo "export DISPLAY=$DISPLAY" >>~/.screenenv
    else
	echo "unset DISPLAY" >>~/.screenenv
    fi
    if [[ -n "$WINDOWID" ]]; then
	echo "export WINDOWID=$WINDOWID" >>~/.screenenv
    else
	echo "unset WINDOWID" >>~/.screenenv
    fi
    if [[ -n "$SSH_TTY" ]]; then
	cat >>~/.screenenv <<EOT
    export SSH_CLIENT="$SSH_CLIENT"
    export SSH_CONNECTION="$SSH_CONNECTION"
    export SSH_TTY=$SSH_TTY
    EOT
    else
	echo "unset SSH_CLIENT SSH_CONNECTION SSH_TTY" >>~/.screenenv
    fi
    if [[ -n "$SESSION_MANAGER" ]]; then
	echo "export SESSION_MANAGER=$SESSION_MANAGER" >>~/.screenenv
    else
	echo "unset SESSION_MANAGER" >>~/.screenenv
    fi

..wayne..

Re: Is zsh buggy in connection with screen?

[Wayne Davison]

On Tue, Nov 08, 2005 at 09:44:11AM -0800, Wayne Davison wrote:
> My update script looks like this (yeah, it's ugly, but it works):

Actually, it had a bug in it early in the output (which changed
recently).  This has prompted me to make it less horrific:

#!/bin/zsh
for var in SSH_AUTH_SOCK SSH_AGENT_PID DISPLAY WINDOWID SSH_TTY SSH_CLIENT SSH_CONNECTION SESSION_MANAGER; do
    if [[ -n "${(P)var}" ]]; then
	echo "export $var=${(P)var}"
    else
	echo "unset $var"
    fi
done >~/.screenenv

..wayne..

Re: Is zsh buggy in connection with screen?

[Sebastian Stein]

Wayne Davison <wayned@users.sourceforge.net> [051108 19:12]:
> On Tue, Nov 08, 2005 at 09:44:11AM -0800, Wayne Davison wrote:
> > My update script looks like this (yeah, it's ugly, but it works):
> 
> Actually, it had a bug in it early in the output (which changed
> recently).  This has prompted me to make it less horrific:
> 
> #!/bin/zsh
> for var in SSH_AUTH_SOCK SSH_AGENT_PID DISPLAY WINDOWID SSH_TTY SSH_CLIENT SSH_CONNECTION SESSION_MANAGER; do
>     if [[ -n "${(P)var}" ]]; then
> 	echo "export $var=${(P)var}"
>     else
> 	echo "unset $var"
>     fi
> done >~/.screenenv

Yeah, from time to time still vim gets killed. Any ideas? Are there other
variables, which must be saved?


Sebastian

Re: Is zsh buggy in connection with screen?

[Wayne Davison]

On Tue, Nov 08, 2005 at 07:16:29PM +0100, Sebastian Stein wrote:
> Yeah, from time to time still vim gets killed. Any ideas? Are there
> other variables, which must be saved?

If you're leaving a vim running, it won't get told about the new
environment values until its next invocation from the shell, so there
may not be anything we can do to prevent it from dying.

You said that bash does not exhibit this problem?  If it's not just pure
chance that prevented prior bash-related failures, you might want to
dump the full set of environment variables from bash-inside-screen and
zsh-inside-screen and look for differences -- perhaps if vim starts up
with some different environment info it behaves differently (that
doesn't seem likely, but it's a possibility)?

..wayne..

Re: Is zsh buggy in connection with screen?

[Paul Johnson]

On Tue, Nov 08, 2005 at 07:16:29PM +0100, Sebastian Stein wrote:

> Yeah, from time to time still vim gets killed. Any ideas?

Pass the -X option to vim?

-- 
Paul Johnson - paul@pjcj.net
http://www.pjcj.net

Re: Is zsh buggy in connection with screen?

[Wayne Davison]

On Tue, Nov 08, 2005 at 10:05:28AM -0800, Wayne Davison wrote:
> 	echo "export $var=${(P)var}"

Note that I neglected to include some quotes around the value on that
line -- it works better like this:

	echo "export $var='${(P)var}'"

..wayne..

Re: Is zsh buggy in connection with screen?

[Sebastian Stein]

Wayne Davison <wayned@users.sourceforge.net> [051108 18:52]:
> On Tue, Nov 08, 2005 at 03:13:17PM +0100, Vincent Lefevre wrote:
> > What is your terminal? xterm for instance sets environment variables
> > that are no longer valid in a different terminal and/or X11 session:
> 
> I use screen too, and have implemented some environment variable
> "tunneling" to ensure that the inner shells get their environment
> updated.  What I did is to write a shell script named "update_screenenv"
> that writes out a set of environment-updating commands into a file named
> ~/.screenenv.  I then alias my normal screen-startup command (which
> happens to be the alias "scr") to run this command before starting
> screen:

Man, you safed my life :-) This is a really awesome solution! It works great
here!


Thanks,


Sebastian
-- 
http://www.halle-ist-schoen.de/
Bilddokumentation der schoensten Saalestadt

Re: Is zsh buggy in connection with screen?

[Tobias Gruetzmacher]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

Hi,

On Tue, Nov 08, 2005 at 07:11:57PM +0100, Sebastian Stein wrote:
> Wayne Davison <wayned@users.sourceforge.net> [051108 18:52]:
> > I use screen too, and have implemented some environment variable
> > "tunneling" to ensure that the inner shells get their environment
> > updated.  What I did is to write a shell script named "update_screenenv"
> > that writes out a set of environment-updating commands into a file named
> > ~/.screenenv.  I then alias my normal screen-startup command (which
> > happens to be the alias "scr") to run this command before starting
> > screen:
> 
> Man, you safed my life :-) This is a really awesome solution! It works great
> here!

It gets ugly if you want to take multiple attached screens into
account. I have a very ugly, very Linux-specific, solution, which even
does not need any special calls while reattaching screen. It imports
the environment variables from the parent shell of the most recently
reattaching screen.

Ah, and it does not work with grsec :)

See: http://portfolio16.de/tmp/zshrc.screen

Greetings Tobi

PS: I know it would be easy to make the script more portable by saving
the environment variables in some temporary file, but I was to lazy to
implement the file-reaping-logic ;)
-- 
GPG-Key 0xE2BEA341 - signed/encrypted mail preferred
My, oh so small, homepage: http://portfolio16.de/
http://www.fli4l.de/ - ISDN- & DSL-Router on one disk!
Registered FLI4L-User #00000003

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Is zsh buggy in connection with screen?

[Ian Langworth]

I have a similar problem with ssh-agent. New screen windows
automatically get the updated environment when I've shelled freshly
into the machine, but existing shells in windows need to run
"latestssh."

# the problem with screen is that old sessions lose ssh-agent awareness. this
# little system fixes it.
local agentdir=~/.latestssh
local agentfile=$agentdir/$HOST.sh
mkdir -p $agentdir
chmod 0700 $agentdir >/dev/null
if [ -n "$SSH_AUTH_SOCK" -a -z $STY ]; then
    echo "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK" >$agentfile
    chmod 0600 $agentfile >/dev/null
fi
# ...existing windows can run this alias
alias latestssh="source $agentfile; ls \$SSH_AUTH_SOCK"
# ...new windows get it automatically
if [ -n "$STY" ]; then
    source $agentfile
fi

--
Ian Langworth

Re: Is zsh buggy in connection with screen?

[Vincent Lefevre]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On 2005-11-08 17:09:42 -0500, Ian Langworth wrote:
> I have a similar problem with ssh-agent. New screen windows
> automatically get the updated environment when I've shelled freshly
> into the machine, but existing shells in windows need to run
> "latestssh."
[...]

I have my own solution for ssh, which is not related to screen,
since I sometimes have several shells on a machine, but without
necessarily using screen. This solution also supports connection
sharing. See the attached message.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

[-- Attachment #2: Type: message/rfc822, Size: 7098 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 3002 bytes --]

This isn't a command, but a set of zsh scripts I've written.
I've attached them. If you want to use them, you basically
need to put these files somewhere in your $fpath, autoload
the corresponding functions with

  autoload -U _call_sshagent _call_sshadd kill_sshmasters

call _call_sshagent from your .zlogin and add the following
to your .zlogout:

# Unregister from ssh-agent and kill it if need be.
if [[ -n $SSH_AUTH_SOCK ]] then
  if [[ `whence -w _call_sshagent` == '_call_sshagent: function' ]] then
    _call_sshagent -r
  elif [[ -n $SSH_AGENT_PID ]] then
    eval `ssh-agent -k`
  fi
fi

and use the following wrappers:

ssh()
{
  _call_sshadd "$@"
  command ssh "$@"
}

slogin()
{
  _call_sshadd "$@"
  command slogin "$@"
}

scp()
{
  _call_sshadd "$@"
  command scp "$@"
}

sftp()
{
  _call_sshadd "$@"
  command sftp "$@"
}

Note: here, these wrappers are defined in .zalias (so is the autoload
line I've mentioned above), sourced by my .zshrc file. Also, I've set
SVN_SSH to $HOME/scripts/ssh; this script contains:

source ~/.zshenv
source ~/.zalias
unset DISPLAY
ssh -C "$@"

Note that $HOME/scripts must not be in $path to avoid an infinite
recursion. In fact, it would be more robust to dynamically remove
$HOME/scripts from $path before calling ssh, after resolving hard
and symbolic links. But there should be no problem if you do not
have '.' in your $path or if you have it at the end (having '.'
earlier in $path is a security problem anyway).

This way, one no longer needs to call ssh-agent and/or ssh-add
manually. The passphrase is automatically asked at the first
connection attempt and remembered until the last login shell
exits. However, one still needs to execute

  ssh -fMN <host>

manually for ssh connection caching. You can add lines to some ssh
wrapper to do that automatically, but you need to check for the
corresponding ControlSocket file first, otherwise there will be no
benefit; unfortunately this is not easy... About these problems,
you can see my bug report and followup here:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335697

Also, note that lsof is used to find the ssh master connection.
If you do not have lsof, the ssh master connection will not be
killed. The kill_sshmasters script has an echo line to let you
know that this connection is killed. So, you know what happens.

Standard disclaimer: use these scripts at your own risks. I've written
them with security in mind, but they haven't be reviewed by anyone
else. Also, I've written them for my config on various machines, and
I'm not sure they work correctly everywhere. You can still check that
ssh-agent is killed when you completely logout with a

  ssh host ps -aef | grep ssh-agent
              ^^^^
or other options depending on your system, and things like that.

-- 
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

[-- Attachment #2.1.2: _call_sshadd --]
[-- Type: text/plain, Size: 403 bytes --]

#!/usr/bin/env zsh

emulate -LR zsh

ssh-add -l >& /dev/null
local err=$?

if [[ $err -eq 2 ]] then
  _call_sshagent -l
  ssh-add -l >& /dev/null
  err=$?
fi

if [[ $err -eq 1 ]] then
  local file i
  file=()
  for i in id_rsa id_rsa-internal identity
  do
    [[ -f $HOME/.ssh/$i ]] && file=($file $HOME/.ssh/$i)
  done
  ssh-add $file
fi

true

# $Id: _call_sshadd 2770 2004-03-17 22:39:32Z lefevre $

[-- Attachment #2.1.3: _call_sshagent --]
[-- Type: text/plain, Size: 2535 bytes --]

#!/usr/bin/env zsh

# Usage: _call_sshagent [ -l | -r ]
#   -l: try to use an existing ssh-agent and change SSH_AUTH_SOCK
#       accordingly. This is useful for some non-login shells (no
#       possible clean-up by the .zlogout).
#   -r: remove the socket associated with the current process and
#       kill ssh-agent if there are no sockets any longer.

emulate -LR zsh

local link=/tmp/ssh-agent-$USER

local i=0
until (ln -s /dev/null $link.lock 2> /dev/null)
do
  [[ $i -eq 0 ]] && echo "$0: waiting for lock"
  if [[ $((++i)) -eq 4 ]] then
    echo "$0: can't lock $link"
    return
  fi
  sleep 2
done

local dir=`readlink $link`

if [[ $1 == -r ]] then

  if [[ -O $link && -d $dir && -O $dir && $SSH_AUTH_SOCK == $link/* ]] then
    local others
    rm -f $SSH_AUTH_SOCK
    unset SSH_AUTH_SOCK
    others=($dir/agent.*(N=))
    if [[ -z $others ]] then
      local pid=$(<$dir/ssh-agent.pid)
      rm -f $link $dir/ssh-agent.pid
      kill -TERM $pid
      kill_sshmasters
    fi
  else
    # Inconsistent data, try to kill ssh-agent in the standard way
    eval `ssh-agent -k`
  fi

elif [[ $1 == -l ]] then

  if [[ -O $link && -d $dir && -O $dir ]] then
    local old
    old=($link/agent.*(N=[1]))
    if [[ -S $old ]] then
      SSH_AUTH_SOCK=$old ssh-add -l >& /dev/null
      if [[ $? -ne 2 ]] then
        export SSH_AUTH_SOCK=$old
        unset SSH_AGENT_PID
      fi
    else
      echo "$0: $old isn't a socket"
    fi
  fi

else

  if [[ -O $link && -d $dir && -O $dir ]] then
    local old
    old=($link/agent.*(N=[1]))
    if [[ -S $old ]] then
      SSH_AUTH_SOCK=$old ssh-add -l >& /dev/null
      if [[ $? -eq 2 ]] then
        # The agent could not be contacted, assume that it has died
        rm -f $dir/agent.*(N) $dir/ssh-agent.pid && rmdir $dir
        rm -f $link
        rm -f $link.lock
        $0
        return
      fi
      local new=$link/agent.$$
      if [[ $new == $old ]] || ln -f $old $new; then
        export SSH_AUTH_SOCK=$new
        unset SSH_AGENT_PID
      else
        echo "$0: can't link $new -> $old"
      fi
    else
      echo "$0: $old isn't a socket"
    fi
  elif eval `ssh-agent`; then
    if ln -fs $SSH_AUTH_SOCK:h $link; then
      local old=$SSH_AUTH_SOCK
      echo $SSH_AGENT_PID > $link/ssh-agent.pid
      rm -f $link.lock
      $0 && rm -f $old
      return
    else
      echo "$0: can't symlink $dir -> $SSH_AUTH_SOCK:h"
    fi
  else
    echo "$0: can't call ssh-agent"
  fi

fi

rm -f $link.lock

# $Id: _call_sshagent 9482 2005-10-25 15:49:48Z lefevre $

[-- Attachment #2.1.4: kill_sshmasters --]
[-- Type: text/plain, Size: 393 bytes --]

#!/usr/bin/env zsh

# Kill the ssh master connections having no slaves.

emulate -LR zsh
local file pid pids

for file in /tmp/ssh-*(=N)
do
  pids=($(lsof -F f -U -a -c ssh -a "$file" 2>/dev/null))
  if [[ $#pids == 2 ]] then
    pid=${pids[1]#p}
    echo "kill $pid (socket $file)"
    kill -TERM $pid
  fi
done

# Never fail.
true

# $Id: kill_sshmasters 9485 2005-10-25 16:08:12Z lefevre $