[vox-tech] screen question

[Peter Jay Salzman]

On Mon 01 Nov 04,  9:07 AM, Ken Bloom <kabloom at ucdavis.edu> said:
> On Mon, 1 Nov 2004 11:53:30 -0500
> p at dirac.org (Peter Jay Salzman) wrote:
> 
> > Thanks Mike.  I did try the remote detach (-d).  It *said* that the
> > session was forcibly detached, but a subsequent "screen -ls" showed
> > the session as still being attached.
> > 
> > Here's an example:
> > 
> > 
> >    # Try to reattach
> >    #
> >    born$ screen -r
> >    There is a screen on:
> >            25783.pts-2.born        (Attached)
> >    There is no screen to be resumed.
> > 
> >    # OK, try to detach.  Looks like it worked.
> >    #
> >    born$ screen -d
> >    [25783.pts-2.born detached.]
> > 
> >    # Apparently, it didn't!
> >    #
> >    born$ screen -ls
> >    There is a screen on:
> >            25783.pts-2.born        (Attached)
> >    1 Socket in /home/psalzman/.screen.
> > 
> >    # Confirmed.  It didn't detach.
> >    #
> >    born$ screen -r
> >    There is a screen on:
> >            25783.pts-2.born        (Attached)
> >    There is no screen to be resumed.
> >    born$ 
> > 
> > 
> > It looks like "screen -R" looks for a screen to be resumed, doesn't
> > find one, so it starts a new screen session.
> > 
> > Looks like I can name the session to be remotely detached/reattached,
> > but that doesn't work either:
> > 
> > 
> >    born$ screen -d 25783.pts-2.born 
> >    [25783.pts-2.born detached.]
> > 
> >    born$ screen -r 25783.pts-2.born 
> >    There is a screen on:
> >            25783.pts-2.born        (Attached)
> >    There is no screen to be resumed matching 25783.pts-2.born.
> > 
> 
> I was able to reproduce this problem in with screen in CSIF.
> screen-3.9.15-10 (that's the same version you've got)
> 
> See if you can work around the problem by using
> $ screen -d -R
> (both parameters at the same time)
> it worked for me.
> 
> --Ken Bloom

Ken, THANK YOU!!!!


What in the world made you try the two switches simultaneously?  And, this is
a bug, right?  :)

Pete