Is there a way to run 'screen' in read-only mode?
I'd like to be able to check progress and output of my existing screen
sessions, but in a read-only manner, so as to prevent something from going wrong due to user error. Is there a way to do this?
gnu-screen
add a comment |
I'd like to be able to check progress and output of my existing screen
sessions, but in a read-only manner, so as to prevent something from going wrong due to user error. Is there a way to do this?
gnu-screen
add a comment |
I'd like to be able to check progress and output of my existing screen
sessions, but in a read-only manner, so as to prevent something from going wrong due to user error. Is there a way to do this?
gnu-screen
I'd like to be able to check progress and output of my existing screen
sessions, but in a read-only manner, so as to prevent something from going wrong due to user error. Is there a way to do this?
gnu-screen
gnu-screen
asked May 25 '11 at 20:17
Naftuli Kay
12.1k55157250
12.1k55157250
add a comment |
add a comment |
5 Answers
5
active
oldest
votes
Unfortunately, I think the answer is no. The asker of this question switched to tmux specifically because it has that feature (you pass the -r
flag when attaching), so if you have the option to switch multiplexers it's probably your best choice
add a comment |
You can try:
aclchg username -w "#"
if you run screen
in multi user mode (but I didn't have to do anything special to make it work when testing it as a single attached user). If you do need to enter multiuser mode, use multiuser on
.
You can use *
for the username to affect all users.
Using +w
instead of -w
enables write mode.
From man screen
:
aclchg usernames permbits list
chacl usernames permbits list
Change permissions for a comma separated list of users. Permission bits are represented as 'r', 'w' and 'x'. Prefixing '+' grants the permission, '-' removes it. The third parameter is a comma separated list of commands and/or windows (specified either by number or title). The special list '#' refers to all windows, '?' to all commands. if usernames consists of a single '*', all known users are affected. A command can be executed when the user has the 'x' bit for it. The user can type input to a window when he has its 'w' bit set and no other user obtains a writelock for this window. Other bits are currently ignored. To withdraw the writelock from another user in window 2: 'aclchg username -w+w 2'. To allow read-only access to the session: 'aclchg username -w "#"'. As soon as a user's name is known to screen he can attach to the session and (per default) has full permissions for all command and windows. Execution permission for the acl commands, `at' and others should also be removed or the user may be able to regain write permission. Rights of the special username nobody cannot be changed (see the "su" command). 'Chacl' is a synonym to 'aclchg'. Multi user mode only.
While that works, it makesscreen
readonly everywhere the screen session is attached which looks like is different from what the OP asked.
– Stéphane Chazelas
Jan 22 '13 at 22:05
1
@StephaneChazelas: I don't see any indication in the question that the OP is concerned about writability in other instances of a multiply-attached session. Besides, theaclcng
command can specify particular users, particular commands and/or particular windows so that's fairly fine granularity. So that's not "everywhere".
– Dennis Williamson
Jan 23 '13 at 1:59
add a comment |
I have found a fairly simple work-around that allows one to monitor the output safely.
Run the following commands immediately after entering the screen session:
echo /tmp/$STY
touch /tmp/$STY
chmod 0600 /tmp/$STY
script -a -f /tmp/$STY
Detach the session with Ctrl-A d and follow the script output, e.g.:
tail -f /tmp/10751.test
add a comment |
My current solution to this is to set the Terminal View to ReadOnly.
Maybe it's too obvious. However, the question didn't require a solution by screen
itself.
looks good to me, with a terminal emulator that supports read-only mode. unfortunately, many terminals does not (gnome/kde terminal does not iirc), but some do (like xfce4-terminal)
– hanshenrik
Dec 8 at 21:47
add a comment |
i wrote a php script called readscreen
to... attach to screen sessions in read-only mode. save it to /usr/bin/readscreen
and run chmod 0555 /usr/bin/readscreen
, and make sure to have php-cli installed with php-pcntl extension, and you can write readscreen
followed by whatever command you'd use to connect with normal screen, for example:
readscreen -S foo -x
and you'll be connected to the foo session in a read-only fashion. note that it's not extensively tested, but seems to work fine. readscreen source code:
#!/usr/bin/env php
<?php
declare(ticks = 1);
init_signals ();
$args = $argv;
unset ( $args [0] );
$args = implode ( " ", array_map ( 'escapeshellarg', $args ) );
// var_dump ( $argc, $argv, $args );
$cmd = "screen {$args}";
echo "executing cmd: $cmdn";
$descriptorspec = array (
0 => array (
"pipe",
"rb"
) // stdin
);
$cwd = NULL;
$env = NULL;
global $screen;
$screen = proc_open ( "script --quiet --return --command " . escapeshellarg ( $cmd )." /dev/null", $descriptorspec, $pipes, $cwd, $env );
global $screen_stdin;
$screen_stdin = $pipes [0];
if (false === $screen) {
echo ("error: failed creating screen process: ");
var_dump ( error_get_last () );
die ( 1 );
}
//fclose(STDIN);
while ( 1 ) {
//echo ".";
sleep ( 1 );
if (! proc_get_status ( $screen ) ['running']) {
echo "error: screen stopped.n";
cleanup ();
die ( 1 );
}
}
function cleanup() {
global $screen;
global $screen_stdin;
echo "detaching from screen. (running cleanup() )n";
fwrite ( $screen_stdin, "1" ); // equivalent of ctrl+AD apparently.
fclose ( $screen_stdin );
$exited = false;
// give it a few seconds to exit itself before killing it
for($i = 0; $i < 3; ++ $i) {
if (! proc_get_status ( $screen ) ['running']) {
$exited = true;
break;
}
sleep ( 1 );
}
if (! $exited) {
echo "Warning: screen did not exit gracefully, killing it now..";
proc_terminate ( $screen, SIGKILL );
while ( proc_get_status ( $screen ) ['running'] ) {
echo ".";
sleep ( 1 );
}
echo "killed.";
}
proc_close ( $screen );
}
function init_signals() {
global $signals;
// all signals that cause termination by default.
$signals = [
"SIGABRT",
"SIGALRM",
"SIGFPE",
"SIGHUP",
"SIGILL",
"SIGINT",
// "SIGKILL",
"SIGPIPE",
"SIGQUIT",
"SIGSEGV",
"SIGTERM",
"SIGUSR1",
"SIGUSR2",
"SIGBUS",
"SIGPOLL",
"SIGPROF",
"SIGSYS",
"SIGTRAP",
"SIGVTALRM",
"SIGXCPU",
"SIGXFSZ"
];
$signals_new = [ ];
foreach ( $signals as $key => $signal ) {
$tmp = constant ( $signal );
if ($tmp === null) {
fprintf ( STDERR, "warning: unknown signal "%s", may not be able to handle it without passing it to screen...n", $singal );
unset ( $signals [$key] );
continue;
}
$signals_new [$signal] = $tmp;
}
$signals = $signals_new;
unset ( $signals_new );
foreach ( $signals as $num ) {
pcntl_signal ( $num, "signal_handler" );
}
}
function signal_handler($signo, $siginfo) {
global $signals;
$sname = array_search ( $signo, $signals, false );
if ($sname === false) {
$sname = "unknown signal";
}
echo "nnerror: got signal " . $signo . " (" . $sname . "), exiting screen session & returning.n";
var_dump ( $siginfo );
cleanup ();
die ();
}
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f13787%2fis-there-a-way-to-run-screen-in-read-only-mode%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
Unfortunately, I think the answer is no. The asker of this question switched to tmux specifically because it has that feature (you pass the -r
flag when attaching), so if you have the option to switch multiplexers it's probably your best choice
add a comment |
Unfortunately, I think the answer is no. The asker of this question switched to tmux specifically because it has that feature (you pass the -r
flag when attaching), so if you have the option to switch multiplexers it's probably your best choice
add a comment |
Unfortunately, I think the answer is no. The asker of this question switched to tmux specifically because it has that feature (you pass the -r
flag when attaching), so if you have the option to switch multiplexers it's probably your best choice
Unfortunately, I think the answer is no. The asker of this question switched to tmux specifically because it has that feature (you pass the -r
flag when attaching), so if you have the option to switch multiplexers it's probably your best choice
edited Apr 13 '17 at 12:36
Community♦
1
1
answered May 25 '11 at 20:24
Michael Mrozek♦
60.5k29187208
60.5k29187208
add a comment |
add a comment |
You can try:
aclchg username -w "#"
if you run screen
in multi user mode (but I didn't have to do anything special to make it work when testing it as a single attached user). If you do need to enter multiuser mode, use multiuser on
.
You can use *
for the username to affect all users.
Using +w
instead of -w
enables write mode.
From man screen
:
aclchg usernames permbits list
chacl usernames permbits list
Change permissions for a comma separated list of users. Permission bits are represented as 'r', 'w' and 'x'. Prefixing '+' grants the permission, '-' removes it. The third parameter is a comma separated list of commands and/or windows (specified either by number or title). The special list '#' refers to all windows, '?' to all commands. if usernames consists of a single '*', all known users are affected. A command can be executed when the user has the 'x' bit for it. The user can type input to a window when he has its 'w' bit set and no other user obtains a writelock for this window. Other bits are currently ignored. To withdraw the writelock from another user in window 2: 'aclchg username -w+w 2'. To allow read-only access to the session: 'aclchg username -w "#"'. As soon as a user's name is known to screen he can attach to the session and (per default) has full permissions for all command and windows. Execution permission for the acl commands, `at' and others should also be removed or the user may be able to regain write permission. Rights of the special username nobody cannot be changed (see the "su" command). 'Chacl' is a synonym to 'aclchg'. Multi user mode only.
While that works, it makesscreen
readonly everywhere the screen session is attached which looks like is different from what the OP asked.
– Stéphane Chazelas
Jan 22 '13 at 22:05
1
@StephaneChazelas: I don't see any indication in the question that the OP is concerned about writability in other instances of a multiply-attached session. Besides, theaclcng
command can specify particular users, particular commands and/or particular windows so that's fairly fine granularity. So that's not "everywhere".
– Dennis Williamson
Jan 23 '13 at 1:59
add a comment |
You can try:
aclchg username -w "#"
if you run screen
in multi user mode (but I didn't have to do anything special to make it work when testing it as a single attached user). If you do need to enter multiuser mode, use multiuser on
.
You can use *
for the username to affect all users.
Using +w
instead of -w
enables write mode.
From man screen
:
aclchg usernames permbits list
chacl usernames permbits list
Change permissions for a comma separated list of users. Permission bits are represented as 'r', 'w' and 'x'. Prefixing '+' grants the permission, '-' removes it. The third parameter is a comma separated list of commands and/or windows (specified either by number or title). The special list '#' refers to all windows, '?' to all commands. if usernames consists of a single '*', all known users are affected. A command can be executed when the user has the 'x' bit for it. The user can type input to a window when he has its 'w' bit set and no other user obtains a writelock for this window. Other bits are currently ignored. To withdraw the writelock from another user in window 2: 'aclchg username -w+w 2'. To allow read-only access to the session: 'aclchg username -w "#"'. As soon as a user's name is known to screen he can attach to the session and (per default) has full permissions for all command and windows. Execution permission for the acl commands, `at' and others should also be removed or the user may be able to regain write permission. Rights of the special username nobody cannot be changed (see the "su" command). 'Chacl' is a synonym to 'aclchg'. Multi user mode only.
While that works, it makesscreen
readonly everywhere the screen session is attached which looks like is different from what the OP asked.
– Stéphane Chazelas
Jan 22 '13 at 22:05
1
@StephaneChazelas: I don't see any indication in the question that the OP is concerned about writability in other instances of a multiply-attached session. Besides, theaclcng
command can specify particular users, particular commands and/or particular windows so that's fairly fine granularity. So that's not "everywhere".
– Dennis Williamson
Jan 23 '13 at 1:59
add a comment |
You can try:
aclchg username -w "#"
if you run screen
in multi user mode (but I didn't have to do anything special to make it work when testing it as a single attached user). If you do need to enter multiuser mode, use multiuser on
.
You can use *
for the username to affect all users.
Using +w
instead of -w
enables write mode.
From man screen
:
aclchg usernames permbits list
chacl usernames permbits list
Change permissions for a comma separated list of users. Permission bits are represented as 'r', 'w' and 'x'. Prefixing '+' grants the permission, '-' removes it. The third parameter is a comma separated list of commands and/or windows (specified either by number or title). The special list '#' refers to all windows, '?' to all commands. if usernames consists of a single '*', all known users are affected. A command can be executed when the user has the 'x' bit for it. The user can type input to a window when he has its 'w' bit set and no other user obtains a writelock for this window. Other bits are currently ignored. To withdraw the writelock from another user in window 2: 'aclchg username -w+w 2'. To allow read-only access to the session: 'aclchg username -w "#"'. As soon as a user's name is known to screen he can attach to the session and (per default) has full permissions for all command and windows. Execution permission for the acl commands, `at' and others should also be removed or the user may be able to regain write permission. Rights of the special username nobody cannot be changed (see the "su" command). 'Chacl' is a synonym to 'aclchg'. Multi user mode only.
You can try:
aclchg username -w "#"
if you run screen
in multi user mode (but I didn't have to do anything special to make it work when testing it as a single attached user). If you do need to enter multiuser mode, use multiuser on
.
You can use *
for the username to affect all users.
Using +w
instead of -w
enables write mode.
From man screen
:
aclchg usernames permbits list
chacl usernames permbits list
Change permissions for a comma separated list of users. Permission bits are represented as 'r', 'w' and 'x'. Prefixing '+' grants the permission, '-' removes it. The third parameter is a comma separated list of commands and/or windows (specified either by number or title). The special list '#' refers to all windows, '?' to all commands. if usernames consists of a single '*', all known users are affected. A command can be executed when the user has the 'x' bit for it. The user can type input to a window when he has its 'w' bit set and no other user obtains a writelock for this window. Other bits are currently ignored. To withdraw the writelock from another user in window 2: 'aclchg username -w+w 2'. To allow read-only access to the session: 'aclchg username -w "#"'. As soon as a user's name is known to screen he can attach to the session and (per default) has full permissions for all command and windows. Execution permission for the acl commands, `at' and others should also be removed or the user may be able to regain write permission. Rights of the special username nobody cannot be changed (see the "su" command). 'Chacl' is a synonym to 'aclchg'. Multi user mode only.
answered Jan 22 '13 at 21:46
Dennis Williamson
5,35812332
5,35812332
While that works, it makesscreen
readonly everywhere the screen session is attached which looks like is different from what the OP asked.
– Stéphane Chazelas
Jan 22 '13 at 22:05
1
@StephaneChazelas: I don't see any indication in the question that the OP is concerned about writability in other instances of a multiply-attached session. Besides, theaclcng
command can specify particular users, particular commands and/or particular windows so that's fairly fine granularity. So that's not "everywhere".
– Dennis Williamson
Jan 23 '13 at 1:59
add a comment |
While that works, it makesscreen
readonly everywhere the screen session is attached which looks like is different from what the OP asked.
– Stéphane Chazelas
Jan 22 '13 at 22:05
1
@StephaneChazelas: I don't see any indication in the question that the OP is concerned about writability in other instances of a multiply-attached session. Besides, theaclcng
command can specify particular users, particular commands and/or particular windows so that's fairly fine granularity. So that's not "everywhere".
– Dennis Williamson
Jan 23 '13 at 1:59
While that works, it makes
screen
readonly everywhere the screen session is attached which looks like is different from what the OP asked.– Stéphane Chazelas
Jan 22 '13 at 22:05
While that works, it makes
screen
readonly everywhere the screen session is attached which looks like is different from what the OP asked.– Stéphane Chazelas
Jan 22 '13 at 22:05
1
1
@StephaneChazelas: I don't see any indication in the question that the OP is concerned about writability in other instances of a multiply-attached session. Besides, the
aclcng
command can specify particular users, particular commands and/or particular windows so that's fairly fine granularity. So that's not "everywhere".– Dennis Williamson
Jan 23 '13 at 1:59
@StephaneChazelas: I don't see any indication in the question that the OP is concerned about writability in other instances of a multiply-attached session. Besides, the
aclcng
command can specify particular users, particular commands and/or particular windows so that's fairly fine granularity. So that's not "everywhere".– Dennis Williamson
Jan 23 '13 at 1:59
add a comment |
I have found a fairly simple work-around that allows one to monitor the output safely.
Run the following commands immediately after entering the screen session:
echo /tmp/$STY
touch /tmp/$STY
chmod 0600 /tmp/$STY
script -a -f /tmp/$STY
Detach the session with Ctrl-A d and follow the script output, e.g.:
tail -f /tmp/10751.test
add a comment |
I have found a fairly simple work-around that allows one to monitor the output safely.
Run the following commands immediately after entering the screen session:
echo /tmp/$STY
touch /tmp/$STY
chmod 0600 /tmp/$STY
script -a -f /tmp/$STY
Detach the session with Ctrl-A d and follow the script output, e.g.:
tail -f /tmp/10751.test
add a comment |
I have found a fairly simple work-around that allows one to monitor the output safely.
Run the following commands immediately after entering the screen session:
echo /tmp/$STY
touch /tmp/$STY
chmod 0600 /tmp/$STY
script -a -f /tmp/$STY
Detach the session with Ctrl-A d and follow the script output, e.g.:
tail -f /tmp/10751.test
I have found a fairly simple work-around that allows one to monitor the output safely.
Run the following commands immediately after entering the screen session:
echo /tmp/$STY
touch /tmp/$STY
chmod 0600 /tmp/$STY
script -a -f /tmp/$STY
Detach the session with Ctrl-A d and follow the script output, e.g.:
tail -f /tmp/10751.test
edited Aug 15 '15 at 3:08
answered Feb 12 '15 at 21:23
Tag
1213
1213
add a comment |
add a comment |
My current solution to this is to set the Terminal View to ReadOnly.
Maybe it's too obvious. However, the question didn't require a solution by screen
itself.
looks good to me, with a terminal emulator that supports read-only mode. unfortunately, many terminals does not (gnome/kde terminal does not iirc), but some do (like xfce4-terminal)
– hanshenrik
Dec 8 at 21:47
add a comment |
My current solution to this is to set the Terminal View to ReadOnly.
Maybe it's too obvious. However, the question didn't require a solution by screen
itself.
looks good to me, with a terminal emulator that supports read-only mode. unfortunately, many terminals does not (gnome/kde terminal does not iirc), but some do (like xfce4-terminal)
– hanshenrik
Dec 8 at 21:47
add a comment |
My current solution to this is to set the Terminal View to ReadOnly.
Maybe it's too obvious. However, the question didn't require a solution by screen
itself.
My current solution to this is to set the Terminal View to ReadOnly.
Maybe it's too obvious. However, the question didn't require a solution by screen
itself.
answered Oct 4 at 6:58
sebkraemer
111
111
looks good to me, with a terminal emulator that supports read-only mode. unfortunately, many terminals does not (gnome/kde terminal does not iirc), but some do (like xfce4-terminal)
– hanshenrik
Dec 8 at 21:47
add a comment |
looks good to me, with a terminal emulator that supports read-only mode. unfortunately, many terminals does not (gnome/kde terminal does not iirc), but some do (like xfce4-terminal)
– hanshenrik
Dec 8 at 21:47
looks good to me, with a terminal emulator that supports read-only mode. unfortunately, many terminals does not (gnome/kde terminal does not iirc), but some do (like xfce4-terminal)
– hanshenrik
Dec 8 at 21:47
looks good to me, with a terminal emulator that supports read-only mode. unfortunately, many terminals does not (gnome/kde terminal does not iirc), but some do (like xfce4-terminal)
– hanshenrik
Dec 8 at 21:47
add a comment |
i wrote a php script called readscreen
to... attach to screen sessions in read-only mode. save it to /usr/bin/readscreen
and run chmod 0555 /usr/bin/readscreen
, and make sure to have php-cli installed with php-pcntl extension, and you can write readscreen
followed by whatever command you'd use to connect with normal screen, for example:
readscreen -S foo -x
and you'll be connected to the foo session in a read-only fashion. note that it's not extensively tested, but seems to work fine. readscreen source code:
#!/usr/bin/env php
<?php
declare(ticks = 1);
init_signals ();
$args = $argv;
unset ( $args [0] );
$args = implode ( " ", array_map ( 'escapeshellarg', $args ) );
// var_dump ( $argc, $argv, $args );
$cmd = "screen {$args}";
echo "executing cmd: $cmdn";
$descriptorspec = array (
0 => array (
"pipe",
"rb"
) // stdin
);
$cwd = NULL;
$env = NULL;
global $screen;
$screen = proc_open ( "script --quiet --return --command " . escapeshellarg ( $cmd )." /dev/null", $descriptorspec, $pipes, $cwd, $env );
global $screen_stdin;
$screen_stdin = $pipes [0];
if (false === $screen) {
echo ("error: failed creating screen process: ");
var_dump ( error_get_last () );
die ( 1 );
}
//fclose(STDIN);
while ( 1 ) {
//echo ".";
sleep ( 1 );
if (! proc_get_status ( $screen ) ['running']) {
echo "error: screen stopped.n";
cleanup ();
die ( 1 );
}
}
function cleanup() {
global $screen;
global $screen_stdin;
echo "detaching from screen. (running cleanup() )n";
fwrite ( $screen_stdin, "1" ); // equivalent of ctrl+AD apparently.
fclose ( $screen_stdin );
$exited = false;
// give it a few seconds to exit itself before killing it
for($i = 0; $i < 3; ++ $i) {
if (! proc_get_status ( $screen ) ['running']) {
$exited = true;
break;
}
sleep ( 1 );
}
if (! $exited) {
echo "Warning: screen did not exit gracefully, killing it now..";
proc_terminate ( $screen, SIGKILL );
while ( proc_get_status ( $screen ) ['running'] ) {
echo ".";
sleep ( 1 );
}
echo "killed.";
}
proc_close ( $screen );
}
function init_signals() {
global $signals;
// all signals that cause termination by default.
$signals = [
"SIGABRT",
"SIGALRM",
"SIGFPE",
"SIGHUP",
"SIGILL",
"SIGINT",
// "SIGKILL",
"SIGPIPE",
"SIGQUIT",
"SIGSEGV",
"SIGTERM",
"SIGUSR1",
"SIGUSR2",
"SIGBUS",
"SIGPOLL",
"SIGPROF",
"SIGSYS",
"SIGTRAP",
"SIGVTALRM",
"SIGXCPU",
"SIGXFSZ"
];
$signals_new = [ ];
foreach ( $signals as $key => $signal ) {
$tmp = constant ( $signal );
if ($tmp === null) {
fprintf ( STDERR, "warning: unknown signal "%s", may not be able to handle it without passing it to screen...n", $singal );
unset ( $signals [$key] );
continue;
}
$signals_new [$signal] = $tmp;
}
$signals = $signals_new;
unset ( $signals_new );
foreach ( $signals as $num ) {
pcntl_signal ( $num, "signal_handler" );
}
}
function signal_handler($signo, $siginfo) {
global $signals;
$sname = array_search ( $signo, $signals, false );
if ($sname === false) {
$sname = "unknown signal";
}
echo "nnerror: got signal " . $signo . " (" . $sname . "), exiting screen session & returning.n";
var_dump ( $siginfo );
cleanup ();
die ();
}
add a comment |
i wrote a php script called readscreen
to... attach to screen sessions in read-only mode. save it to /usr/bin/readscreen
and run chmod 0555 /usr/bin/readscreen
, and make sure to have php-cli installed with php-pcntl extension, and you can write readscreen
followed by whatever command you'd use to connect with normal screen, for example:
readscreen -S foo -x
and you'll be connected to the foo session in a read-only fashion. note that it's not extensively tested, but seems to work fine. readscreen source code:
#!/usr/bin/env php
<?php
declare(ticks = 1);
init_signals ();
$args = $argv;
unset ( $args [0] );
$args = implode ( " ", array_map ( 'escapeshellarg', $args ) );
// var_dump ( $argc, $argv, $args );
$cmd = "screen {$args}";
echo "executing cmd: $cmdn";
$descriptorspec = array (
0 => array (
"pipe",
"rb"
) // stdin
);
$cwd = NULL;
$env = NULL;
global $screen;
$screen = proc_open ( "script --quiet --return --command " . escapeshellarg ( $cmd )." /dev/null", $descriptorspec, $pipes, $cwd, $env );
global $screen_stdin;
$screen_stdin = $pipes [0];
if (false === $screen) {
echo ("error: failed creating screen process: ");
var_dump ( error_get_last () );
die ( 1 );
}
//fclose(STDIN);
while ( 1 ) {
//echo ".";
sleep ( 1 );
if (! proc_get_status ( $screen ) ['running']) {
echo "error: screen stopped.n";
cleanup ();
die ( 1 );
}
}
function cleanup() {
global $screen;
global $screen_stdin;
echo "detaching from screen. (running cleanup() )n";
fwrite ( $screen_stdin, "1" ); // equivalent of ctrl+AD apparently.
fclose ( $screen_stdin );
$exited = false;
// give it a few seconds to exit itself before killing it
for($i = 0; $i < 3; ++ $i) {
if (! proc_get_status ( $screen ) ['running']) {
$exited = true;
break;
}
sleep ( 1 );
}
if (! $exited) {
echo "Warning: screen did not exit gracefully, killing it now..";
proc_terminate ( $screen, SIGKILL );
while ( proc_get_status ( $screen ) ['running'] ) {
echo ".";
sleep ( 1 );
}
echo "killed.";
}
proc_close ( $screen );
}
function init_signals() {
global $signals;
// all signals that cause termination by default.
$signals = [
"SIGABRT",
"SIGALRM",
"SIGFPE",
"SIGHUP",
"SIGILL",
"SIGINT",
// "SIGKILL",
"SIGPIPE",
"SIGQUIT",
"SIGSEGV",
"SIGTERM",
"SIGUSR1",
"SIGUSR2",
"SIGBUS",
"SIGPOLL",
"SIGPROF",
"SIGSYS",
"SIGTRAP",
"SIGVTALRM",
"SIGXCPU",
"SIGXFSZ"
];
$signals_new = [ ];
foreach ( $signals as $key => $signal ) {
$tmp = constant ( $signal );
if ($tmp === null) {
fprintf ( STDERR, "warning: unknown signal "%s", may not be able to handle it without passing it to screen...n", $singal );
unset ( $signals [$key] );
continue;
}
$signals_new [$signal] = $tmp;
}
$signals = $signals_new;
unset ( $signals_new );
foreach ( $signals as $num ) {
pcntl_signal ( $num, "signal_handler" );
}
}
function signal_handler($signo, $siginfo) {
global $signals;
$sname = array_search ( $signo, $signals, false );
if ($sname === false) {
$sname = "unknown signal";
}
echo "nnerror: got signal " . $signo . " (" . $sname . "), exiting screen session & returning.n";
var_dump ( $siginfo );
cleanup ();
die ();
}
add a comment |
i wrote a php script called readscreen
to... attach to screen sessions in read-only mode. save it to /usr/bin/readscreen
and run chmod 0555 /usr/bin/readscreen
, and make sure to have php-cli installed with php-pcntl extension, and you can write readscreen
followed by whatever command you'd use to connect with normal screen, for example:
readscreen -S foo -x
and you'll be connected to the foo session in a read-only fashion. note that it's not extensively tested, but seems to work fine. readscreen source code:
#!/usr/bin/env php
<?php
declare(ticks = 1);
init_signals ();
$args = $argv;
unset ( $args [0] );
$args = implode ( " ", array_map ( 'escapeshellarg', $args ) );
// var_dump ( $argc, $argv, $args );
$cmd = "screen {$args}";
echo "executing cmd: $cmdn";
$descriptorspec = array (
0 => array (
"pipe",
"rb"
) // stdin
);
$cwd = NULL;
$env = NULL;
global $screen;
$screen = proc_open ( "script --quiet --return --command " . escapeshellarg ( $cmd )." /dev/null", $descriptorspec, $pipes, $cwd, $env );
global $screen_stdin;
$screen_stdin = $pipes [0];
if (false === $screen) {
echo ("error: failed creating screen process: ");
var_dump ( error_get_last () );
die ( 1 );
}
//fclose(STDIN);
while ( 1 ) {
//echo ".";
sleep ( 1 );
if (! proc_get_status ( $screen ) ['running']) {
echo "error: screen stopped.n";
cleanup ();
die ( 1 );
}
}
function cleanup() {
global $screen;
global $screen_stdin;
echo "detaching from screen. (running cleanup() )n";
fwrite ( $screen_stdin, "1" ); // equivalent of ctrl+AD apparently.
fclose ( $screen_stdin );
$exited = false;
// give it a few seconds to exit itself before killing it
for($i = 0; $i < 3; ++ $i) {
if (! proc_get_status ( $screen ) ['running']) {
$exited = true;
break;
}
sleep ( 1 );
}
if (! $exited) {
echo "Warning: screen did not exit gracefully, killing it now..";
proc_terminate ( $screen, SIGKILL );
while ( proc_get_status ( $screen ) ['running'] ) {
echo ".";
sleep ( 1 );
}
echo "killed.";
}
proc_close ( $screen );
}
function init_signals() {
global $signals;
// all signals that cause termination by default.
$signals = [
"SIGABRT",
"SIGALRM",
"SIGFPE",
"SIGHUP",
"SIGILL",
"SIGINT",
// "SIGKILL",
"SIGPIPE",
"SIGQUIT",
"SIGSEGV",
"SIGTERM",
"SIGUSR1",
"SIGUSR2",
"SIGBUS",
"SIGPOLL",
"SIGPROF",
"SIGSYS",
"SIGTRAP",
"SIGVTALRM",
"SIGXCPU",
"SIGXFSZ"
];
$signals_new = [ ];
foreach ( $signals as $key => $signal ) {
$tmp = constant ( $signal );
if ($tmp === null) {
fprintf ( STDERR, "warning: unknown signal "%s", may not be able to handle it without passing it to screen...n", $singal );
unset ( $signals [$key] );
continue;
}
$signals_new [$signal] = $tmp;
}
$signals = $signals_new;
unset ( $signals_new );
foreach ( $signals as $num ) {
pcntl_signal ( $num, "signal_handler" );
}
}
function signal_handler($signo, $siginfo) {
global $signals;
$sname = array_search ( $signo, $signals, false );
if ($sname === false) {
$sname = "unknown signal";
}
echo "nnerror: got signal " . $signo . " (" . $sname . "), exiting screen session & returning.n";
var_dump ( $siginfo );
cleanup ();
die ();
}
i wrote a php script called readscreen
to... attach to screen sessions in read-only mode. save it to /usr/bin/readscreen
and run chmod 0555 /usr/bin/readscreen
, and make sure to have php-cli installed with php-pcntl extension, and you can write readscreen
followed by whatever command you'd use to connect with normal screen, for example:
readscreen -S foo -x
and you'll be connected to the foo session in a read-only fashion. note that it's not extensively tested, but seems to work fine. readscreen source code:
#!/usr/bin/env php
<?php
declare(ticks = 1);
init_signals ();
$args = $argv;
unset ( $args [0] );
$args = implode ( " ", array_map ( 'escapeshellarg', $args ) );
// var_dump ( $argc, $argv, $args );
$cmd = "screen {$args}";
echo "executing cmd: $cmdn";
$descriptorspec = array (
0 => array (
"pipe",
"rb"
) // stdin
);
$cwd = NULL;
$env = NULL;
global $screen;
$screen = proc_open ( "script --quiet --return --command " . escapeshellarg ( $cmd )." /dev/null", $descriptorspec, $pipes, $cwd, $env );
global $screen_stdin;
$screen_stdin = $pipes [0];
if (false === $screen) {
echo ("error: failed creating screen process: ");
var_dump ( error_get_last () );
die ( 1 );
}
//fclose(STDIN);
while ( 1 ) {
//echo ".";
sleep ( 1 );
if (! proc_get_status ( $screen ) ['running']) {
echo "error: screen stopped.n";
cleanup ();
die ( 1 );
}
}
function cleanup() {
global $screen;
global $screen_stdin;
echo "detaching from screen. (running cleanup() )n";
fwrite ( $screen_stdin, "1" ); // equivalent of ctrl+AD apparently.
fclose ( $screen_stdin );
$exited = false;
// give it a few seconds to exit itself before killing it
for($i = 0; $i < 3; ++ $i) {
if (! proc_get_status ( $screen ) ['running']) {
$exited = true;
break;
}
sleep ( 1 );
}
if (! $exited) {
echo "Warning: screen did not exit gracefully, killing it now..";
proc_terminate ( $screen, SIGKILL );
while ( proc_get_status ( $screen ) ['running'] ) {
echo ".";
sleep ( 1 );
}
echo "killed.";
}
proc_close ( $screen );
}
function init_signals() {
global $signals;
// all signals that cause termination by default.
$signals = [
"SIGABRT",
"SIGALRM",
"SIGFPE",
"SIGHUP",
"SIGILL",
"SIGINT",
// "SIGKILL",
"SIGPIPE",
"SIGQUIT",
"SIGSEGV",
"SIGTERM",
"SIGUSR1",
"SIGUSR2",
"SIGBUS",
"SIGPOLL",
"SIGPROF",
"SIGSYS",
"SIGTRAP",
"SIGVTALRM",
"SIGXCPU",
"SIGXFSZ"
];
$signals_new = [ ];
foreach ( $signals as $key => $signal ) {
$tmp = constant ( $signal );
if ($tmp === null) {
fprintf ( STDERR, "warning: unknown signal "%s", may not be able to handle it without passing it to screen...n", $singal );
unset ( $signals [$key] );
continue;
}
$signals_new [$signal] = $tmp;
}
$signals = $signals_new;
unset ( $signals_new );
foreach ( $signals as $num ) {
pcntl_signal ( $num, "signal_handler" );
}
}
function signal_handler($signo, $siginfo) {
global $signals;
$sname = array_search ( $signo, $signals, false );
if ($sname === false) {
$sname = "unknown signal";
}
echo "nnerror: got signal " . $signo . " (" . $sname . "), exiting screen session & returning.n";
var_dump ( $siginfo );
cleanup ();
die ();
}
edited Dec 9 at 8:21
answered Dec 9 at 0:11
hanshenrik
10810
10810
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f13787%2fis-there-a-way-to-run-screen-in-read-only-mode%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown