Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!bsu-cs!dhesi From: dhesi@bsu-cs.bsu.edu (Rahul Dhesi) Newsgroups: comp.os.minix Subject: Re: job control is a bug, not a feature Message-ID: <7687@bsu-cs.bsu.edu> Date: 10 Jun 89 21:06:39 GMT References: <16497@louie.udel.EDU> <11989@bcsaic.UUCP> <2775@munnari.oz> <798@gara.une.oz> <8167@boring.cwi.nl> <1989Jun7.224933.700@utzoo.uucp> <1989Jun8.172420.27288@utzoo.uucp> <7652@bsu-cs.bsu.edu> <1989Jun10.063315.26085@utzoo.uucp> Reply-To: dhesi@bsu-cs.bsu.edu (Rahul Dhesi) Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 62 Countering Henry Spencer's response to my article: Job control versus multiple windows is a false dichotomy because one does not exclude the other. >>2. Each and every program does not need special code to deal with >> job control. Only programs that change terminal settings, >> and privileged programs that should not be interrupted by >> unprivileged users, need such code. > >And any program for which there is any likelihood that its output might >have to be redrawn. That is, every program. No. If a program produces strictly sequential output, you only need to redraw it if it has scrolled off your screen or been overwritten by the output from some other screen-oriented program. But this is not caused by job control, so job control should not be blamed for it. If you want all output from a program to be always accessible, you need a virtual screen much bigger than your physical screen. Multiple windows are neither necessary nor sufficient to give you that. >>3. Multiple windows are useless at 1200 bps. > >Then don't put more than one on the screen at a time. The others are still >accessible if needed. It takes too long to redraw the screen at 1200 bps. Switching between windows is painful at less then 9600 bps, and even at 9600 bps it is an inconvenience. >>4. Multiple windows are useless on a hardcopy terminal. > >True. How many people work on hardcopy terminals? I don't know. I occasionally do when I need a record of what I did. How do you make a log of everything you did in a terminal session in order while still using multiple windows? Re job control + windows: >Why provide two ways of doing the same thing? One of them doesn't work well under certain circumstances, such as 1200 bps, and the other doesn't let you flexibly handle concurrent jobs that produce output to the screen. If you value both situations you need both job control and multiple windows. For jobs that expect no input from the terminal, I find it most convenient to redirect all output to a log file. This effectively gives me a much bigger window into the output than any conventional windowing scheme would. And at any time I can do "tail -f logfile" and see the output in real time, and I can even suspend *this* job (running tail) and resume it later if I wish. If we all had high-speed links (at least 19.2 kbps), and big terminals (perhaps 100 characters by 100 lines), multiple windows might be the perfect replacement for job control. Perhaps in 1995 or so Henry Spencer's claims will be indisputable. -- Rahul Dhesi UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume