Re: prompt and ssh

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2009-05-21 20:37:47 -0700, Bart Schaefer wrote:
> On May 22,  3:08am, Vincent Lefevre wrote:
> } I also do the following:
> } 1. Start screen remotely (via ssh).
> } 2. Detach the screen session.
> } 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. And if you don't consider the port, you can have a
false positive as soon as there is an active ssh connection
between the two machines.

> } One should also find a way to make it work with several screen
> } sessions (in screen, that can be identified by $STY, so that the
> } filename could be based on it).
> 
> That's a bit problematic, because the file has to be written by the
> shell "outside" the screen session, but $STY is only available to
> the shell "inside" screen.  That is, $STY doesn't exist yet at the
> point when you need to write the file.

There are two cases:

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
   session. However if the form "screen cmd" is used while no shell
   rc file is run, the file cannot be created; in such a case, the
   -S option would be required to make it work (if these environment
   variables will be needed).

This assumes no race condition, but a race condition is very unlikely.

> That requires that (in the calling login shell) you always provide
> the sessionname argument, because if you use just -R or -RR the
> caller doesn't know what file to write.

The man page says:

  -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.

> } When screen terminates, one should check if the session still exists
> } (attached or detached), and if it isn't, remove the file.
> 
> It's unfortunate that screen -ls exits with nonzero status even if it
> finds a matching session.

Yes, perhaps a bug? (The behavior isn't documented.)

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)