[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: confusion over -R argument

From: Clark Wang
Subject: Re: confusion over -R argument
Date: Fri, 28 Mar 2014 14:29:34 +0800

On Fri, Mar 28, 2014 at 3:53 AM, Liam Hopkins <address@hidden> wrote:

I am trying to understand the -R argument. It doesn't seem to behave in
the way the man page indicates it ought. `screen -v` shows:
Screen version 4.00.03jw4 (FAU) 2-May-06

relevant `man screen` snippet:

# -R   attempts to resume the youngest (in terms of creation time) detached
# screen session it finds.  

Interesting. The man page (for screen version 4.00.03 (FAU) 23-Oct-06) on my system says this:

.    -R   attempts to resume the first detached screen session it finds.

If successful, all other command-line options are
# ignored.  If no detached session exists, starts a new session using the
# specified options, just as if -R had not been specified.  The  option  is set
# by default if screen is run as a login-shell (actually screen uses "-xRR" in
# that case).  For combinations with the -d/-D option see there.  Note:
# Time-based session selection is a Debian addition.

So it's a Debian specific feature. You may go ask the Debian list. :)

OK! So if I have a list of screen sessions shown by `screen -ls` as
(detached), `screen -R` ought to reconnect to the most recent one. It
doesn't; it behaves as `screen -r`, prompting "There are several
suitable screens on:"...

Further, adding an argument works, but only for some arguments. `screen
-R bash` will create a new session named 'bash' (despite available detached
sessions), but `screen -R /bin/bash` seems to again use `screen -r`
behavior and trigger the multiuser mode warning:

"Must run suid root for multiuser support."

What must I do to gain my desired behavior, whereby screen reattaches to
an available detached screen, otherwise starts '/bin/bash -l' ?


screen-users mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]