Zsh Mailing List Archive
Messages sorted by:
Re: prompt and ssh
- X-seq: zsh-users 14161
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxxxxx
- Subject: Re: prompt and ssh
- Date: Fri, 22 May 2009 07:36:12 -0700
- In-reply-to: <20090522081926.GV27141@xxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <e7db6e960905190954j7be72739p6b521bca8e90fe7f@xxxxxxxxxxxxxx> <20090519200217.35368.qmail@xxxxxxxxxxx> <20090521074103.GN27141@xxxxxxxxxxxxxxxxxxx> <090521092207.ZM14221@xxxxxxxxxxxxxxxxxxxxxx> <20090522010850.GU27141@xxxxxxxxxxxxxxxxxxx> <090521203747.ZM15323@xxxxxxxxxxxxxxxxxxxxxx> <20090522081926.GV27141@xxxxxxxxxxxxxxxxxxx>
On May 22, 10:19am, Vincent Lefevre wrote:
} Subject: Re: prompt and ssh
} On 2009-05-21 20:37:47 -0700, Bart Schaefer wrote:
} > On May 22, 3:08am, Vincent Lefevre wrote:
} > } 3. Resume the screen session from a different ssh connection (e.g.
} > } because the first one has died -- BTW, this is even one of the
} > } reasons of using screen).
} > ... is one of the situations the netstat test is meant to discover.
} No, because the port $SSH_CONNECTION[(w)2] is, in general, not
} the same.
Yes, exactly. So the grep would not find that connection in the output
of netstat, the "else" branch would be taken, and you'd know that you
need to reload the value of SSH_CONNECTION from somewhere.
As I said, though, it's harmless to simply always reload the values, so
in this context the test is only of academic interest.
I noticed while testing that always reloading has an additional benefit:
You pick up changes in the SSH_AGENT environment. A useful extension
would be to pick up changes in forwarded X11 connections, etc.
} 1. If a screen session is resumed or if a -S option is provided, then
} $STY can be guessed by parsing the options, and possibly by using
} the output of "screen -ls", e.g. in case of "screen -r".
} 2. If a screen session doesn't exist yet and a -S option isn't
} provided, then do not create a file: create it from the screen
If you read the two functions I posted, this is in fact what they do,
though I didn't bother handling the "-r" case.
} -R attempts to resume the youngest (in terms of creation time)
} detached screen session it finds.
} As the creation time is provided by "screen -ls", it is possible
} to find the session name.
} > } When resuming a screen session, one should detect
} > } which one, and use a filename corresponding to this session.
} > I don't know any good way to do that from "outside" of screen. Maybe
} > something involving using the -X option could be hacked up.
} See above.
Parsing the output of screen -ls in order to sort by date is not what
I'd call a "good way". :-) In any event it's not something I'm
interested in working out; so, left as an exercise.
Messages sorted by: