Thread View: comp.sources.d
2 messages
2 total messages
Started by Larry W. Virden ext. 2487
Sat, 15 Jun 1991 11:09
query: screen or user?
Author: Larry W. Virden ext. 2487
Date: Sat, 15 Jun 1991 11:09
Date: Sat, 15 Jun 1991 11:09
31 lines
1927 bytes
1927 bytes
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
Re: query: screen or user?
Author: Frotz
Date: Wed, 19 Jun 1991 03:58
Date: Wed, 19 Jun 1991 03:58
44 lines
2632 bytes
2632 bytes
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)
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads