lwv27@CAS.BITNET (Larry W. Virden ext. 2487) (06/15/91)
while using the screen command, I see a particular problem upon which I would like comment . Let's say that, due to a typo, I do something dumb like fgrep a /etc/aliases in a screen window. This results in a) a lot of output and b) me realizing immediately that I did something dumb. An even dumber thing that can happen is that I write a shell or C which loops forever outputting text. The problem comes when I try to either ^C the window or kill the window. It APPEARS to me that sending requests to the screen command results in things queued up UNTIL OUTPUT CEASES. Now, this may have something to do with the setup of reading sockets for the output. I do not know. I do know that it means that if I do not try to stop a window in the instant before output beings, I am stuck watching the output until a pause occurs. And of course, fgrep , etc. never pause. Other than never making mistakes, or powering off my terminal, what kinds of changes could be made to a program like screen to become sensitive to user input requests during output? Remember there are two types of user input! There are the input strokes to the current application and there are input strokes intended for screen. The ones intended for screen are the ones I would like to take place at the instant, or soon there after, that they occur. -- Larry W. Virden UUCP: osu-cis!chemabs!lwv27 Same Mbox: BITNET: lwv27@cas INET: lwv27%cas.BITNET@CUNYVM.CUNY.Edu Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614 America Online: lvirden
frotz@dri.com (Frotz) (06/19/91)
lwv27@CAS.BITNET (Larry W. Virden ext. 2487) writes:
]while using the screen command, I see a particular problem upon which
]I would like comment .
]The problem comes when I try to either ^C the window or kill the window.
]It APPEARS to me that sending requests to the screen command results
]in things queued up UNTIL OUTPUT CEASES. Now, this may have something
]to do with the setup of reading sockets for the output. I do not know.
]I do know that it means that if I do not try to stop a window in the
]instant before output beings, I am stuck watching the output until
]a pause occurs. And of course, fgrep , etc. never pause.
We are running: screen 2.3-PreRelease10 15-Apr-91
ansi 2.3-PreRelease10 15-Apr-91
What I have seen with this version (I really like it alot!-) is that
we get about 1 full screen full of output after screen accepts the
command (whatever it was) before things happen. This is fine at
speeds like 9600 or 19200, however, at home on my 1200 baud line, this
is deadly...;-( I find myself keeping all of my screens cleared of
junk whenever possible so that as I browse through each, I don't have
to wait for a refresh before the next screen command is executed.
What would be ideal (don't know if they know about it yet, (Wayne are
you out there:-?)) is if screen(l) were smart enough to determine that
it: a) received it's command character AND b) received a followup
action keystroke, that it interrupt the output in the current window
and perform the command *immediately*. The danger with this is having
a window that is not fully redrawn and waiting for a follow-up action
keystroke.
]Other than never making mistakes, or powering off my terminal, what
]kinds of changes could be made to a program like screen to become
]sensitive to user input requests during output?
The prerelease version that we are running seems to run fine other
than at *very* slow speeds...;-)
--
John "Frotz" Fa'atuai frotz@dri.com (email@domain)
Digital Research, Inc. uunet!drivax!frotz (bang!email)
c/o MIS Dept. 408/647-6570 or 408/646-6287 (vmail)
80 Garden Court, CompRm 408/649-3896 (phone)
Monterey, CA 93940 408/646-6248 (fax)