* Is zsh buggy in connection with screen?
@ 2005-11-08 13:02 Sebastian Stein
2005-11-08 14:13 ` Vincent Lefevre
0 siblings, 1 reply; 12+ messages in thread
From: Sebastian Stein @ 2005-11-08 13:02 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 13:02 Is zsh buggy in connection with screen? Sebastian Stein
@ 2005-11-08 14:13 ` Vincent Lefevre
2005-11-08 17:44 ` Wayne Davison
0 siblings, 1 reply; 12+ messages in thread
From: Vincent Lefevre @ 2005-11-08 14:13 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 14:13 ` Vincent Lefevre
@ 2005-11-08 17:44 ` Wayne Davison
2005-11-08 18:05 ` Wayne Davison
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Wayne Davison @ 2005-11-08 17:44 UTC (permalink / raw)
To: zsh-users
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..
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 17:44 ` Wayne Davison
@ 2005-11-08 18:05 ` Wayne Davison
2005-11-08 18:16 ` Sebastian Stein
2005-11-08 22:34 ` Wayne Davison
2005-11-08 18:11 ` Sebastian Stein
2005-11-08 22:09 ` Ian Langworth
2 siblings, 2 replies; 12+ messages in thread
From: Wayne Davison @ 2005-11-08 18:05 UTC (permalink / raw)
To: zsh-users
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..
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 17:44 ` Wayne Davison
2005-11-08 18:05 ` Wayne Davison
@ 2005-11-08 18:11 ` Sebastian Stein
2005-11-08 19:34 ` Tobias Gruetzmacher
2005-11-08 22:09 ` Ian Langworth
2 siblings, 1 reply; 12+ messages in thread
From: Sebastian Stein @ 2005-11-08 18:11 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 18:05 ` Wayne Davison
@ 2005-11-08 18:16 ` Sebastian Stein
2005-11-08 18:44 ` Wayne Davison
2005-11-08 20:06 ` Paul Johnson
2005-11-08 22:34 ` Wayne Davison
1 sibling, 2 replies; 12+ messages in thread
From: Sebastian Stein @ 2005-11-08 18:16 UTC (permalink / raw)
To: zsh-users
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 18:16 ` Sebastian Stein
@ 2005-11-08 18:44 ` Wayne Davison
2005-11-08 20:06 ` Paul Johnson
1 sibling, 0 replies; 12+ messages in thread
From: Wayne Davison @ 2005-11-08 18:44 UTC (permalink / raw)
To: Sebastian Stein; +Cc: zsh-users
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..
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 18:11 ` Sebastian Stein
@ 2005-11-08 19:34 ` Tobias Gruetzmacher
0 siblings, 0 replies; 12+ messages in thread
From: Tobias Gruetzmacher @ 2005-11-08 19:34 UTC (permalink / raw)
To: zsh-users
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 18:16 ` Sebastian Stein
2005-11-08 18:44 ` Wayne Davison
@ 2005-11-08 20:06 ` Paul Johnson
1 sibling, 0 replies; 12+ messages in thread
From: Paul Johnson @ 2005-11-08 20:06 UTC (permalink / raw)
To: Sebastian Stein; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 17:44 ` Wayne Davison
2005-11-08 18:05 ` Wayne Davison
2005-11-08 18:11 ` Sebastian Stein
@ 2005-11-08 22:09 ` Ian Langworth
2005-11-22 9:47 ` Vincent Lefevre
2 siblings, 1 reply; 12+ messages in thread
From: Ian Langworth @ 2005-11-08 22:09 UTC (permalink / raw)
To: Wayne Davison; +Cc: zsh-users
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 18:05 ` Wayne Davison
2005-11-08 18:16 ` Sebastian Stein
@ 2005-11-08 22:34 ` Wayne Davison
1 sibling, 0 replies; 12+ messages in thread
From: Wayne Davison @ 2005-11-08 22:34 UTC (permalink / raw)
To: zsh-users
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..
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Is zsh buggy in connection with screen?
2005-11-08 22:09 ` Ian Langworth
@ 2005-11-22 9:47 ` Vincent Lefevre
0 siblings, 0 replies; 12+ messages in thread
From: Vincent Lefevre @ 2005-11-22 9:47 UTC (permalink / raw)
To: zsh-users
[-- 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 $
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-11-22 9:47 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-08 13:02 Is zsh buggy in connection with screen? Sebastian Stein
2005-11-08 14:13 ` Vincent Lefevre
2005-11-08 17:44 ` Wayne Davison
2005-11-08 18:05 ` Wayne Davison
2005-11-08 18:16 ` Sebastian Stein
2005-11-08 18:44 ` Wayne Davison
2005-11-08 20:06 ` Paul Johnson
2005-11-08 22:34 ` Wayne Davison
2005-11-08 18:11 ` Sebastian Stein
2005-11-08 19:34 ` Tobias Gruetzmacher
2005-11-08 22:09 ` Ian Langworth
2005-11-22 9:47 ` Vincent Lefevre
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).