* 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 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: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 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 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: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 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 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).