Path: utzoo!attcan!uunet!samsung!sol.ctr.columbia.edu!emory!mephisto!prism!gt0178a
From: gt0178a@prism.gatech.EDU (BURNS,JIM)
Newsgroups: comp.unix.questions
Subject: Re: screen program information
Message-ID: <13840@hydra.gatech.EDU>
Date: 19 Sep 90 08:39:44 GMT
References: <26143:Sep1811:47:4890@kramden.acf.nyu.edu>
Organization: Georgia Institute of Technology
Lines: 56

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