On Mon 01 Nov 04, 9:07 AM, Ken Bloom <[EMAIL PROTECTED]> said: > On Mon, 1 Nov 2004 11:53:30 -0500 > [EMAIL PROTECTED] (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 _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
