On Fri, Oct 02, 2009 at 12:09:57PM +1000, Ben Finney wrote: > On 02-Oct-2009, Paul Bone wrote: > > I have several screen sessions running: > > > > pb...@paper:~$ screen -r > > There are several suitable screens on: > > 13468.677_project2 (01/10/09 16:03:13) (Detached) > > 10259.bug66 (23/09/09 11:09:18) (Detached) > > 6870.mail (23/09/09 09:00:53) (Attached) > > Type "screen [-d] -r [pid.]tty.host" to resume one of them. > > > > And I want to resume working on 677_project2, so I use the > > unambiguous prefix '677'. > > > > pb...@paper:~$ screen -r 677 > > There is no screen to be resumed matching 677. > […] > > > I understand that a number might represent a PID rather than a name, > > but the full name was definitely unambiguous, and since I had no > > screens running as PID 677 the short name should also be considered > > unambiguous. > > Also of note: the ‘screen(1)’ man page gives the following synopsis: > > screen -r [[pid.]tty[.host]] > screen -r sessionowner/[[pid.]tty[.host]] > > The sequence ‘677’ can't possibly be specifying a PID by the above > synopsis: > > * Is it matching “pid ‘.’ tty ‘.’ host”? No, since there are no > periods in the string. > > * Is it matching “pid ‘.’ tty”? again no, for the same reason. > > In other words, the only way to specify a PID to be resumed is if it > is immediately followed by a period, then the TTY. There is no > allowance by the above synopsis for specifying a PID alone as a > sequence of digits. > > So, if the code is attempting to match a PID from a sequence > consisting only of digits, it is not conforming to the documentation. >
I agree. We don't know if that's the cause though.
signature.asc
Description: Digital signature
