Chauhan@system-m.phx.bull.com (Ardaman Chauhan (TDC)) (09/13/90)
Greetings All :
This is the first time i am posting to the net so please
excuse me if i goof up.
I downloaded the screen program from the net a while back and
found it very useful. I have a question about the detach/attach feature
of the program by which you can detach a process and after wards
reattach to the same process from some other terminal/login.
Could somebody be kind enough to explain me the basic idea
about that feature, how it is implemented (main points). The source
doesnot have many comments. I have asked because an enquiring mind
wants to know. I am a regular reader of this forum, so you can send me
the response or if you think suitable, post to the forum.
Thanks in advance Ardaman S. Chauhan TSDC Chauhan -at
system-m.bull.combrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/14/90)
In article <24491@adm.BRL.MIL> Chauhan@system-m.phx.bull.com (Ardaman Chauhan (TDC)) writes: > I downloaded the screen program from the net a while back and > found it very useful. I have a question about the detach/attach feature > of the program by which you can detach a process and after wards > reattach to the same process from some other terminal/login. It sets up blocking IPC files, either named pipes or bound UNIX-domain sockets. All communication goes through the files. Reconnecting is just a matter of reopening the files. (Of course, this adds an unnecessary layer of communication. It's more efficient to pass file descriptors back and forth, like pty does.) ---Dan
dale@mks.com (Dale Gass) (09/16/90)
In article <7598:Sep1407:49:4190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <24491@adm.BRL.MIL> Chauhan@system-m.phx.bull.com (Ardaman Chauhan (TDC)) writes: >> I downloaded the screen program from the net a while back and >> found it very useful. I have a question about the detach/attach feature >> of the program by which you can detach a process and after wards >> reattach to the same process from some other terminal/login. > >It sets up blocking IPC files, either named pipes or bound UNIX-domain >sockets. All communication goes through the files. Reconnecting is >just a matter of reopening the files. Not quite so. The sockets are only used for passing relatively infrequent control messages (for creating new screen sessions by running screen within a screen window, for reattaching, and for sending error messages). When screen starts, it forks into two processes, one of which does all the screen work. The second process is a dummy process which is used solely for suspend/detach/resume support. When one suspends or detaches screen, the main screen process goes into the background, and either stops (for suspend) or kills (for detach) the dummy process; since the dummy process still has the user's login terminal as it's controlling terminal, the shell that started screen will be notified, and regain control. (The main screen process is still lurking in the background at this point). Looking at the screen source code, it's not entirely obvious when the main program goes into the background; it does this in a somewhat subtle manner, by closing all file descriptors and then disassociating itself with the controlling terminal with an ioctl() call. Once in the background, it simply processes incoming messages through the control socket until it is no longer suspended (at which point it goes back to it's main purpose of shuffling characters between the user's controlling terminal and the screen sessions' pseudo-terminals). The messages which tell screen to continue (MSG_CONT and MSG_ATTACH) cause screen's main process to open the user's login terminal. Since all it's files were close at this point, this causes the user's login terminal to become the controlling process for screen. Thus, screen effectively has control of the user's terminal again. The reattach messages are sent in one of two ways; a "screen -r" will send this message, as well as "fg %1" (or any similar method of continuing stopped processes), which will continue the stopped dummy process. (This second method will only work if screen was suspended, not detached.) The dummy process traps the SIGCONT; when a SIGCONT occurs, it sends the reattach message to the main screen process (which should be waiting for such a message in the background). No special processing (or closing/reopening) is required for the screen sessions during a suspend/detach. They will continue processing until they attempt to get input from the pseudo terminal, at which point they will block, or until they send enough output to fill up the pty's buffer, at which point they will also block. When screen is restarted, it will handle all pending output from, and sending input to the screen sessions. >(Of course, this adds an unnecessary layer of communication. There is only one layer of communication; the screen program passing characters from the user's login tty, and a session's pseudo-terminal. The socket operations happen very infrequently, and should impose little or no processing overhead during normal use. In porting screen to Interactive Unix Sys V, I removed the suspend/detach/reattach code for the sake of simplicity. It reduced the code size by about 600 lines, and made things a lot more readable. Screen's source can be a bit intimidating at first; however, most of the confusing stuff is related to the detach/reattach feature. Once one understands how this works, the rest of the code is quite striaght forward. Studying and understanding screen's source is very educational; it exercises a lot of useful unix concepts (controlling terminals, pseudo terminals, job control, sockets, signals, termcaps, interprocess communication, terminal modes, login records, environments, load average, curses-like screen management, etc.) -dale dale@mks.com uunet!watmath!mks!dale
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/16/90)
In article <1990Sep16.021433.27054@mks.com> dale@femto.mks.com (Dale Gass) writes: > In article <7598:Sep1407:49:4190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: [ about screen ] > > (Of course, this adds an unnecessary layer of communication. > There is only one layer of communication; the screen program passing > characters from the user's login tty, and a session's pseudo-terminal. Sorry, you're entirely right. What I should have said was that screen's reconnect structure unnecessarily removes a layer of flexibility: you can't bring a screen session back into the middle of a pipe. ---Dan
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/16/90)
in article <18996:Sep1609:58:2090@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) says: > Sorry, you're entirely right. What I should have said was that screen's > reconnect structure unnecessarily removes a layer of flexibility: you > can't bring a screen session back into the middle of a pipe. ^^^^^^^^^^^^^^^^ Huh? Since I use screen, could you give an example of what you mean by this last phrase? Thanx. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
src@scuzzy.in-berlin.de (Heiko Blume) (09/18/90)
dale@mks.com (Dale Gass) writes: >In porting screen to Interactive Unix Sys V, I removed the >suspend/detach/reattach code for the sake of simplicity. It reduced >the code size by about 600 lines, and made things a lot more readable. i suppose you did that for 2.0.2? since 2.2 has job control, have you done a port for it ? -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/18/90)
In article <13716@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes:
[ on screen's reconnect abilities ]
Two examples of things I use pty for all the time:
1. Flushing output reliably. If a program starts flooding the screen
with output, I can just break the connection. Then I come back with a
command like sess -T reconnect qf > /tmp/flood, type ^C when the flood
stops, and reconnect normally. How can screen do this? (Typing ^O isn't
reliable---it is delayed by the communications program and doesn't work
in raw mode---and loses possibly important output.)
2. Using a macro package. I have a context-sensitive, programmable
keyboard and screen macro package running around pty. It simply pipes
the input and output of pty appropriately. How can screen do this?
Have I missed some of screen's features?
---Dangt0178a@prism.gatech.EDU (BURNS,JIM) (09/19/90)
in article <26143:Sep1811:47:4890@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) says: > Two examples of things I use pty for all the time: > 1. Flushing output reliably. If a program starts flooding the screen > with output, I can just break the connection. Then I come back with a > command like sess -T reconnect qf > /tmp/flood, type ^C when the flood > stops, and reconnect normally. How can screen do this? (Typing ^O isn't > reliable---it is delayed by the communications program and doesn't work > in raw mode---and loses possibly important output.) Well, of course I could always just ^a-k (kill) that screen window w/o affecting any of my other windows, then ^a-c ((re-) create) that window if I need it. > 2. Using a macro package. I have a context-sensitive, programmable > keyboard and screen macro package running around pty. It simply pipes > the input and output of pty appropriately. How can screen do this? Living w/multiple levels of control char. interpretations is nothing new. I often find myself doing something like this: I use shl(1) on my SysV system at work, which has its control seqs. for switching between multiple HP-UX sessions (w/o screen redraw :-( ), start up cu(1) or kermit, which have their own local command seqs., dial up my university's NIU, whose controls interpret connect/disconnect and Xon/Xoff (faster than the host at any rate), connect to Dynix where I use 'screen', and occaisionally telnet/rlogin from there to SunOS, A/UX, or Ultrix, and of course telnet has its own local commands. And then, there is vi(1)'s local macros. Works fine as long as none of the control seqs. collide, and most of these packages allow for redefining their escape seqs, for compatibility w/ something more sophisticated like keyboard macro packages. Of course, if I actually do a file xfer in kermit, I usually have to detach screen and play w/ the NIU settings (for binary files at least). > Have I missed some of screen's features? On the whole, I doubt it since you've read screen's source code and I haven't gotten around to it myself. However, maybe I'm being dense, but how did you answer my original question? You said: in article <18996:Sep1609:58:2090@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) says: > you can't bring a screen session back into the middle of a pipe. [and I said] ^^^^^^^^^^^^^^^^ Huh? You can certainly detach screen while a command is outputting lots of info, and reconnect where you left off. What's an example of a command seq. using a *pipe* that you can't return to? And finally, when ARE you going to post pty to c.u.s? :-) -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/19/90)
in article <13840@hydra.gatech.EDU>, I write: > Well, of course I could always just ^a-k (kill) that screen window w/o > affecting any of my other windows, then ^a-c ((re-) create) that window if > I need it. Then again, I suppose this wouldn't be appropriate if the program needs to update files after the output is finished, or then returns to interactive communication, and you don't want to spend a lot of time reconstructing the state of the program up to then. Does redirecting output of 'sess' drain the output fairly quickly, or do you have to guess how long it takes? Some netstat(1) output can take forever just to be generated! -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/19/90)
in article <13842@hydra.gatech.EDU>, I write: > in article <13840@hydra.gatech.EDU>, I write: >> Well, of course I could always just ^a-k (kill) that screen window w/o >> affecting any of my other windows, then ^a-c ((re-) create) that window if >> I need it. > Then again, I suppose this wouldn't be appropriate if the program needs to And then again, since this *is* a windowing package, I can just switch to another window and do something else while I'm waiting. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/21/90)
In article <13840@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS,JIM) writes: > Well, of course I could always just ^a-k (kill) that screen window w/o > affecting any of my other windows, then ^a-c ((re-) create) that window if > I need it. I said flush, not eliminate. Say you accidentally cat /etc/termcap without a pager running. Say there's about 50K of buffering between you and the nearest communications mechanism that knows how to flush output. Are you going to wait for that 50K to drain? Under pty, you just sess -T reconnect p5 > /dev/null, or perhaps pipe it through more, or perhaps save it in a file for later perusal. Then you type ^C and reconnect normally, without harming any other background processes or stopped jobs in the session. How can you do this under screen? > in article <18996:Sep1609:58:2090@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) says: > > you can't bring a screen session back into the middle of a pipe. > [and I said] ^^^^^^^^^^^^^^^^ Huh? You write your amazing macro program. You want to have it handle both the input and output of screen. How do you do this? > And finally, when ARE you going to post pty to c.u.s? :-) pty 3.001 and pty 3.001 patch 1 should appear any moment now on comp.sources.unix. Complain at Rich. In the meantime they're available via anonymous ftp to 128.122.128.22 or upon request to me. ---Dan
gt0178a@prism.gatech.EDU (BURNS,JIM) (09/21/90)
in article <13861:Sep2105:07:0790@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) says: > I said flush, not eliminate. Say you accidentally cat /etc/termcap > without a pager running. Say there's about 50K of buffering between you > and the nearest communications mechanism that knows how to flush output. > Are you going to wait for that 50K to drain? Well, in this case, I *would* kill it & restart it w/ a pager, & use '/' to search forward to where I was, but I get the idea in general. (1) > Under pty, you just sess -T reconnect p5 > /dev/null, or perhaps pipe it > through more, or perhaps save it in a file for later perusal. Then you > type ^C and reconnect normally, without harming any other background > processes or stopped jobs in the session. How can you do this under > screen? (2) > You write your amazing macro program. You want to have it handle both > the input and output of screen. How do you do this? I gather *both* of these examples are refering to something like "...| sess|...", ala your answer in c.u.internals about a Spy program. In that case, I misunderstood your comment about "bring[ing] a screen session back into the middle of a pipe". I thought you were talking about existing pipelines *inside* the session, which screen does handle. Yes, 'screen' itself does not talk to stdin/out, so can't be piped. Thanx again for your reply. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
dale@mks.com (Dale Gass) (09/22/90)
In article <1990Sep17.235600.17863@scuzzy.in-berlin.de> src@scuzzy.in-berlin.de (Heiko Blume) writes: >I write: >>In porting screen to Interactive Unix Sys V, I removed the >>suspend/detach/reattach code for the sake of simplicity. It reduced >>the code size by about 600 lines, and made things a lot more readable. > >i suppose you did that for 2.0.2? since 2.2 has job control, have you >done a port for it ? I will be adding suspend susport for screen on Interactive (using the job control). It should be quite straight forward. -dale
henkl@glorantha (Henk Langeveld - Sun Nederland) (09/24/90)
gt0178a@prism.gatech.EDU (BURNS,JIM) writes: >in article <13842@hydra.gatech.EDU>, I write: > >> in article <13840@hydra.gatech.EDU>, I write: >>> Well, of course I could always just ^a-k (kill) that screen window w/o >>> affecting any of my other windows, then ^a-c ((re-) create) that window if >>> I need it. >> Then again, I suppose this wouldn't be appropriate if the program needs to >And then again, since this *is* a windowing package, I can just switch to >another window and do something else while I'm waiting. Well, that's one problem I have with 'screen', when logged in from home over a 1200 bps line and I type 'cat HUGEFILE' in stead of 'less HUGEFILE' I have to bash ^C real fast, or spend the next ten minutes waiting for the file to flow by. Apparently, interrupts aren't handled asynchronously by 'screen'. No matter what I do, the only way to get out of it is to switch the modem off and on, and build a new connection. Fortunately, by the time I 'screen -r', all output from the offending window has been flushed to never-never-land, and I can continue where I took^H^H^H^H left off. :-) I must say that 'screen' is the one free program I use most. I wonder though, the program has been very stable since its first release in 1988. I have only seen one patch, and nothing else. Aren't there people out there who've added features to it ? -- Henk Langeveld, (henkl@holland.sun.com // henkl@sun.nl) Confiction, 48th world SF Con: Aug 23-27th, The Hague. I've seen the mouse die. -sniff- Going to demolish the confiction@... address, use this instead.
gordon@prls.UUCP (Gordon Vickers) (09/25/90)
This is unrelated to the present disscusion, but .....
From the "For What It's Worth Department":
Isn't SCREEN great ! I depend upon it everyday. I only wished
I had the time to study the source so I could make some changes.
As I understand it, Screen will only emulate VT100's. I always thought
it would be nice if it would just default to what ever type of terminal
the user had. I often use one or more screens to log onto other computers,
so VT100 isn't always a good choice. Ideally, it would be nice if
terminal type could be set on a per screen baises.
I have also liked Screen's ability to prohibit most ESC sequences
from effecting the real terminal, but this is also sometimes a henderance.
It would be more conviniant to have this capability switched at will
to effect the currently displayed screen only.
I wonder if Oliver (the author) is tired of supporting this terrific
program ? I wonder if he is tired of getting suggestions ? He has
certainly put a lot of time into supporting Screen ! Thanks Oliver !
Gordon Vickers 408/991-5370 {mips,pyramid|philabs}!prls!gordon
Signetics in Sunnyvale,Ca (USA)
Earth is a complex array of symbiotic relationships: Every extinction, whether
animal, mineral, vegetable, or cultural hastens our own demise.gt0178a@prism.gatech.EDU (BURNS,JIM) (09/26/90)
in article <2561@ehq-ir-1.UK.Sun.COM>, henkl@glorantha (Henk Langeveld - Sun Nederland) says: > Well, that's one problem I have with 'screen', when logged in from home > over a 1200 bps line and I type 'cat HUGEFILE' in stead of 'less HUGEFILE' > I have to bash ^C real fast, or spend the next ten minutes waiting for > the file to flow by. Apparently, interrupts aren't handled > asynchronously by 'screen'. No matter what I do, the only way to > get out of it is to switch the modem off and on, and build a new > connection. I don't know how your system buffering works, but I never have to wait longer than about 1 min. till ^C takes effect. About the same time for kill (^A-c) also. -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
jay@gdx.UUCP (Jay A. Snyder) (09/28/90)
Has anyone out there ported this program to the SysV or Xenix environment? ( it uses the BSD select() call) -- ============================================================================== Jay A. Snyder "Let Me Up! I've had enough" wa3wbu!gdx!jay@uunet.uu.net uunet!wa3wbu!gdx!jay