What does a screen session “attaches to the appropriate terminal” after attaching to a Screen session mean?
Clash Royale CLAN TAG#URR8PPP
-2
From https://unix.stackexchange.com/a/486621/674
when you run screen -r to reconnect to an existing session, it
connects to the existing process using a socket, negotiates various
settings, and when it’s good to go, attaches to the appropriate
terminal, and closes the socket.
What does "attaches to the appropriate terminal" mean?
Does it mean that after a Screen client attaches to a Screen session via socket, the client opens the master side of the pseudoterminal underlying the session process?
Thanks.
gnu-screen socket pseudoterminal
asked Jan 5 at 23:05
TimTim
26.4k75250459
|
show 2 more comments
-2
From https://unix.stackexchange.com/a/486621/674
when you run screen -r to reconnect to an existing session, it
connects to the existing process using a socket, negotiates various
settings, and when it’s good to go, attaches to the appropriate
terminal, and closes the socket.
What does "attaches to the appropriate terminal" mean?
Does it mean that after a Screen client attaches to a Screen session via socket, the client opens the master side of the pseudoterminal underlying the session process?
Thanks.
gnu-screen socket pseudoterminal
asked Jan 5 at 23:05
TimTim
26.4k75250459
Could you please make your question a bit more logical, so it could be answered by describing to the actual behavior of thescreenprogram, instead of forcing the answerer into a critical appraisal of someone else's ideas about it ;-) FWIW a screen client process (the one you start withscreen -rto attach to a running instace) does not attach to any tty: it just tells the server (via a socket or a fifo) the path of the tty it was started from, and then sits and waits in order to confuse the shell it was started from.
– mosvy
Jan 6 at 0:38
The screen client never talks to the underlying sessions. The client talks to the server process. The server process manages the sessions and the ptys. When you press the key 'x' the client sends 'x' to the server process. The server process sends it to the appropriate pty. Similarly when the session writes the string 'xyz' to the pty, it's received by the server process, which sends it to the client, and the client writes to your screen. This also explains how multiple clients can connect to the same screen session.
– Stephen Harris
Jan 6 at 1:03
@StephenHarris Just curious, if re-write the whole program, how about the client just send its own fd to server, the server can just copy data to that fd, read input from that fd, instead of sending actual data through Unix domain socket. The logic you're describing seems need to copy the data twice. Once from server to client, twice from client to its own fd (or you may say the actual terminal emulator who is rendering characters).
– 炸鱼薯条德里克
Jan 6 at 1:22
@炸鱼薯条德里克 You may be able to pass file descriptors across the UDP socket, and have the server write directly to the terminal. The server would have to do escape sequence translation between the "Screen" escape sequences and the native terminal(s) - which could be different in a shared session. In both cases, though, the client never talks to the session ptys, just to the server. There may be some local processing, however; scrollback, which screen to view, etc, may make sense to process in the local client session. Dunno.
– Stephen Harris
Jan 6 at 1:35
@StephenHarris the client does not send any key to the server, does not read anything from the server, and does not pass any fds. If you don't believe it, do the following: start a freshscreeninstance, detach from it, and then reattach withstrace -fo /path/to/tty/from/another/window screen -rand start typing away into it. Look at the strace output: where are the reads and the writes?
– mosvy
Jan 6 at 1:45
|
show 2 more comments
-2
-2
-2
From https://unix.stackexchange.com/a/486621/674
when you run screen -r to reconnect to an existing session, it
connects to the existing process using a socket, negotiates various
settings, and when it’s good to go, attaches to the appropriate
terminal, and closes the socket.
What does "attaches to the appropriate terminal" mean?
Does it mean that after a Screen client attaches to a Screen session via socket, the client opens the master side of the pseudoterminal underlying the session process?
Thanks.
gnu-screen socket pseudoterminal
asked Jan 5 at 23:05
TimTim
26.4k75250459
From https://unix.stackexchange.com/a/486621/674
when you run screen -r to reconnect to an existing session, it
connects to the existing process using a socket, negotiates various
settings, and when it’s good to go, attaches to the appropriate
terminal, and closes the socket.
What does "attaches to the appropriate terminal" mean?
Does it mean that after a Screen client attaches to a Screen session via socket, the client opens the master side of the pseudoterminal underlying the session process?
Thanks.
gnu-screen socket pseudoterminal
gnu-screen socket pseudoterminal
asked Jan 5 at 23:05
TimTim
26.4k75250459
asked Jan 5 at 23:05
TimTim
26.4k75250459
asked Jan 5 at 23:05
TimTim
26.4k75250459
asked Jan 5 at 23:05
TimTim
26.4k75250459
asked Jan 5 at 23:05
TimTim
26.4k75250459
26.4k75250459
Could you please make your question a bit more logical, so it could be answered by describing to the actual behavior of thescreenprogram, instead of forcing the answerer into a critical appraisal of someone else's ideas about it ;-) FWIW a screen client process (the one you start withscreen -rto attach to a running instace) does not attach to any tty: it just tells the server (via a socket or a fifo) the path of the tty it was started from, and then sits and waits in order to confuse the shell it was started from.
– mosvy
Jan 6 at 0:38
The screen client never talks to the underlying sessions. The client talks to the server process. The server process manages the sessions and the ptys. When you press the key 'x' the client sends 'x' to the server process. The server process sends it to the appropriate pty. Similarly when the session writes the string 'xyz' to the pty, it's received by the server process, which sends it to the client, and the client writes to your screen. This also explains how multiple clients can connect to the same screen session.
– Stephen Harris
Jan 6 at 1:03
@StephenHarris Just curious, if re-write the whole program, how about the client just send its own fd to server, the server can just copy data to that fd, read input from that fd, instead of sending actual data through Unix domain socket. The logic you're describing seems need to copy the data twice. Once from server to client, twice from client to its own fd (or you may say the actual terminal emulator who is rendering characters).
– 炸鱼薯条德里克
Jan 6 at 1:22
@炸鱼薯条德里克 You may be able to pass file descriptors across the UDP socket, and have the server write directly to the terminal. The server would have to do escape sequence translation between the "Screen" escape sequences and the native terminal(s) - which could be different in a shared session. In both cases, though, the client never talks to the session ptys, just to the server. There may be some local processing, however; scrollback, which screen to view, etc, may make sense to process in the local client session. Dunno.
– Stephen Harris
Jan 6 at 1:35
@StephenHarris the client does not send any key to the server, does not read anything from the server, and does not pass any fds. If you don't believe it, do the following: start a freshscreeninstance, detach from it, and then reattach withstrace -fo /path/to/tty/from/another/window screen -rand start typing away into it. Look at the strace output: where are the reads and the writes?
– mosvy
Jan 6 at 1:45
|
show 2 more comments
Could you please make your question a bit more logical, so it could be answered by describing to the actual behavior of thescreenprogram, instead of forcing the answerer into a critical appraisal of someone else's ideas about it ;-) FWIW a screen client process (the one you start withscreen -rto attach to a running instace) does not attach to any tty: it just tells the server (via a socket or a fifo) the path of the tty it was started from, and then sits and waits in order to confuse the shell it was started from.
– mosvy
Jan 6 at 0:38
The screen client never talks to the underlying sessions. The client talks to the server process. The server process manages the sessions and the ptys. When you press the key 'x' the client sends 'x' to the server process. The server process sends it to the appropriate pty. Similarly when the session writes the string 'xyz' to the pty, it's received by the server process, which sends it to the client, and the client writes to your screen. This also explains how multiple clients can connect to the same screen session.
– Stephen Harris
Jan 6 at 1:03
@StephenHarris Just curious, if re-write the whole program, how about the client just send its own fd to server, the server can just copy data to that fd, read input from that fd, instead of sending actual data through Unix domain socket. The logic you're describing seems need to copy the data twice. Once from server to client, twice from client to its own fd (or you may say the actual terminal emulator who is rendering characters).
– 炸鱼薯条德里克
Jan 6 at 1:22
@炸鱼薯条德里克 You may be able to pass file descriptors across the UDP socket, and have the server write directly to the terminal. The server would have to do escape sequence translation between the "Screen" escape sequences and the native terminal(s) - which could be different in a shared session. In both cases, though, the client never talks to the session ptys, just to the server. There may be some local processing, however; scrollback, which screen to view, etc, may make sense to process in the local client session. Dunno.
– Stephen Harris
Jan 6 at 1:35
@StephenHarris the client does not send any key to the server, does not read anything from the server, and does not pass any fds. If you don't believe it, do the following: start a freshscreeninstance, detach from it, and then reattach withstrace -fo /path/to/tty/from/another/window screen -rand start typing away into it. Look at the strace output: where are the reads and the writes?
– mosvy
Jan 6 at 1:45
Could you please make your question a bit more logical, so it could be answered by describing to the actual behavior of the
screen program, instead of forcing the answerer into a critical appraisal of someone else's ideas about it ;-) FWIW a screen client process (the one you start with screen -r to attach to a running instace) does not attach to any tty: it just tells the server (via a socket or a fifo) the path of the tty it was started from, and then sits and waits in order to confuse the shell it was started from.– mosvy
Jan 6 at 0:38
Could you please make your question a bit more logical, so it could be answered by describing to the actual behavior of the
screen program, instead of forcing the answerer into a critical appraisal of someone else's ideas about it ;-) FWIW a screen client process (the one you start with screen -r to attach to a running instace) does not attach to any tty: it just tells the server (via a socket or a fifo) the path of the tty it was started from, and then sits and waits in order to confuse the shell it was started from.– mosvy
Jan 6 at 0:38
The screen client never talks to the underlying sessions. The client talks to the server process. The server process manages the sessions and the ptys. When you press the key 'x' the client sends 'x' to the server process. The server process sends it to the appropriate pty. Similarly when the session writes the string 'xyz' to the pty, it's received by the server process, which sends it to the client, and the client writes to your screen. This also explains how multiple clients can connect to the same screen session.
– Stephen Harris
Jan 6 at 1:03
The screen client never talks to the underlying sessions. The client talks to the server process. The server process manages the sessions and the ptys. When you press the key 'x' the client sends 'x' to the server process. The server process sends it to the appropriate pty. Similarly when the session writes the string 'xyz' to the pty, it's received by the server process, which sends it to the client, and the client writes to your screen. This also explains how multiple clients can connect to the same screen session.
– Stephen Harris
Jan 6 at 1:03
@StephenHarris Just curious, if re-write the whole program, how about the client just send its own fd to server, the server can just copy data to that fd, read input from that fd, instead of sending actual data through Unix domain socket. The logic you're describing seems need to copy the data twice. Once from server to client, twice from client to its own fd (or you may say the actual terminal emulator who is rendering characters).
– 炸鱼薯条德里克
Jan 6 at 1:22
@StephenHarris Just curious, if re-write the whole program, how about the client just send its own fd to server, the server can just copy data to that fd, read input from that fd, instead of sending actual data through Unix domain socket. The logic you're describing seems need to copy the data twice. Once from server to client, twice from client to its own fd (or you may say the actual terminal emulator who is rendering characters).
– 炸鱼薯条德里克
Jan 6 at 1:22
@炸鱼薯条德里克 You may be able to pass file descriptors across the UDP socket, and have the server write directly to the terminal. The server would have to do escape sequence translation between the "Screen" escape sequences and the native terminal(s) - which could be different in a shared session. In both cases, though, the client never talks to the session ptys, just to the server. There may be some local processing, however; scrollback, which screen to view, etc, may make sense to process in the local client session. Dunno.
– Stephen Harris
Jan 6 at 1:35
@炸鱼薯条德里克 You may be able to pass file descriptors across the UDP socket, and have the server write directly to the terminal. The server would have to do escape sequence translation between the "Screen" escape sequences and the native terminal(s) - which could be different in a shared session. In both cases, though, the client never talks to the session ptys, just to the server. There may be some local processing, however; scrollback, which screen to view, etc, may make sense to process in the local client session. Dunno.
– Stephen Harris
Jan 6 at 1:35
@StephenHarris the client does not send any key to the server, does not read anything from the server, and does not pass any fds. If you don't believe it, do the following: start a fresh
screen instance, detach from it, and then reattach with strace -fo /path/to/tty/from/another/window screen -r and start typing away into it. Look at the strace output: where are the reads and the writes?– mosvy
Jan 6 at 1:45
@StephenHarris the client does not send any key to the server, does not read anything from the server, and does not pass any fds. If you don't believe it, do the following: start a fresh
screen instance, detach from it, and then reattach with strace -fo /path/to/tty/from/another/window screen -r and start typing away into it. Look at the strace output: where are the reads and the writes?– mosvy
Jan 6 at 1:45
|
show 2 more comments
0
active
oldest
votes
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
);
);
draft saved
draft discarded
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%2f492721%2fwhat-does-a-screen-session-attaches-to-the-appropriate-terminal-after-attachin%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
draft saved
draft discarded
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.
draft saved
draft discarded
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%2f492721%2fwhat-does-a-screen-session-attaches-to-the-appropriate-terminal-after-attachin%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
Could you please make your question a bit more logical, so it could be answered by describing to the actual behavior of the
screenprogram, instead of forcing the answerer into a critical appraisal of someone else's ideas about it ;-) FWIW a screen client process (the one you start withscreen -rto attach to a running instace) does not attach to any tty: it just tells the server (via a socket or a fifo) the path of the tty it was started from, and then sits and waits in order to confuse the shell it was started from.– mosvy
Jan 6 at 0:38
The screen client never talks to the underlying sessions. The client talks to the server process. The server process manages the sessions and the ptys. When you press the key 'x' the client sends 'x' to the server process. The server process sends it to the appropriate pty. Similarly when the session writes the string 'xyz' to the pty, it's received by the server process, which sends it to the client, and the client writes to your screen. This also explains how multiple clients can connect to the same screen session.
– Stephen Harris
Jan 6 at 1:03
@StephenHarris Just curious, if re-write the whole program, how about the client just send its own fd to server, the server can just copy data to that fd, read input from that fd, instead of sending actual data through Unix domain socket. The logic you're describing seems need to copy the data twice. Once from server to client, twice from client to its own fd (or you may say the actual terminal emulator who is rendering characters).
– 炸鱼薯条德里克
Jan 6 at 1:22
@炸鱼薯条德里克 You may be able to pass file descriptors across the UDP socket, and have the server write directly to the terminal. The server would have to do escape sequence translation between the "Screen" escape sequences and the native terminal(s) - which could be different in a shared session. In both cases, though, the client never talks to the session ptys, just to the server. There may be some local processing, however; scrollback, which screen to view, etc, may make sense to process in the local client session. Dunno.
– Stephen Harris
Jan 6 at 1:35
@StephenHarris the client does not send any key to the server, does not read anything from the server, and does not pass any fds. If you don't believe it, do the following: start a fresh
screeninstance, detach from it, and then reattach withstrace -fo /path/to/tty/from/another/window screen -rand start typing away into it. Look at the strace output: where are the reads and the writes?– mosvy
Jan 6 at 1:45