mills%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET (Gary Mills) (10/15/87)
Has anyone succeeded in putting a pager into the shell? I am getting a bit tired of appending ` | pg' to any command line that I suspect will generate more than a screen of output. It should be smart enough to reset its line count at each shell prompt so I don't have to keep clearing the screen before commands. I'm not asking for too much, am I? :-) This is System V and we have source. -Gary Mills- <mills@cc.uofm.cdn> -University of Manitoba- -Winnipeg, Canada-
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/15/87)
In article <9779@brl-adm.ARPA> mills%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET (Gary Mills) writes: >Has anyone succeeded in putting a pager into the shell? Wrong place. The shell doesn't handle output characters from the processes it invokes, so it has no opportunity to paginate them. Some people have added pagination to the tty handler. You have to be careful that it is somehow disabled during screen editors, etc.
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (10/17/87)
In article <9779@brl-adm.ARPA>, mills%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET (Gary Mills) writes: > Has anyone succeeded in putting a pager into the shell? I am getting > a bit tired of appending ` | pg' to any command line that I suspect > will generate more than a screen of output. It should be smart enough > to reset its line count at each shell prompt so I don't have to keep > clearing the screen before commands. I'm not asking for too much, > am I? :-) This is System V and we have source. > > -Gary Mills- <mills@cc.uofm.cdn> > -University of Manitoba- > -Winnipeg, Canada- I tried to do this without writing another C program. I put this in an executable shell file called 'page': exec /bin/sh | pg When you want pagination, type in page, and all the output from /bin/sh and all the commands you execute will go to pg. Now the bad part, I couldn't get pg to read its input line by line, maybe theres some option? You could probably change pg to get the behavior you want. I think sh line buffers its output so hopefully you won't have to change it too. I also tried this initially, exec /bin/sh 2>&1 | pg But sh sends PS1 and PS2 down stderr and pg didn't print them, not sure why, maybe the buffering again (or perhaps PS1 should have a newline in it). This also has the disadvantage that stderr is always sent down the pipe. Once you type in ^D you'll be back at your login shell so you can use commands like vi. When all else fails change the tty driver. Someone already suggested this, but I think it may have been premature. We os types love to change things, especially the kernel! When all *else* fails, change the kernel, or buy piece of hardware to do this. I have a terminal with 4 screens of local screen memory (a Teletype 4425), and I can see any of it with some special keys on the left side of the keyboard. I wouldn't say your asking for too much just something most UNIX* users don't need. Personnally I would be very annoyed with it, but that doesn't matter. Larry Cipriani cbosgd!osu-cis!tut!lvc (just a partime grad student) * UNIX is a registered trademark of Ken Thompson.
jpdres10@usl-pc.UUCP (Green Eric Lee) (10/18/87)
Distribution: Keywords: Summary: Expires: Sender: Reply-To: Followup-To: In message <9779@brl-adm.ARPA>, mills%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET (Gary Mills) says: >Has anyone succeeded in putting a pager into the shell? I am getting >a bit tired of appending ` | pg' to any command line that I suspect >will generate more than a screen of output. I'm not sure if that's smart. After a short time of using page-mode terminals connected to an IBM mainframe, one is usually overdue for a sanity check :-). Also, there's some problems with detirmining what exactly starts a page. For example, you type "mailx". And get dumped to the mail reader prompt. You type "h" to see the titles. Hmm, that should count as a part of a page, right? Then you type "3" to read message number 3. Two lines into reading message number 3, the !#$"$"$!"$ thing stops and asks for "---MORE?---". In which case you're tempted to do like that guy in San Francisco did (blew away his IBM PC with a .44 Magnum :-). As for implementation, there's two things you can do: Make stdin and stdout pipes to your shell, or implement paging at the kernel level. For pipes, there's no way of knowing if your characters have been read, and thus, you don't know when the first page began (you can say that a page starts after the last read() call). And of course I won't even begin to try to justify cluttering up the kernel with yet more useless junk (that's currently done perfectly well at the user level, albeit by typing an extra three characters -- big deal). -- Eric Green elg@usl.CSNET from BEYOND nowhere: {ihnp4,cbosgd}!killer!elg, P.O. Box 92191, Lafayette, LA 70509 {ut-sally,killer}!usl!elg "there's someone in my head, but it's not me..."
levy@ttrdc.UUCP (Daniel R. Levy) (10/18/87)
In article <9779@brl-adm.ARPA>, mills%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET (Gary Mills) writes: > Has anyone succeeded in putting a pager into the shell? I am getting > a bit tired of appending ` | pg' to any command line that I suspect > will generate more than a screen of output... > I'm not asking for too much, > am I? :-) This is System V and we have source. Sorry for the post, but the return address looked forbidding. A "pager in the shell" would require piping the standard output of commands into some kind of paginator process just like you do manually now with "| pg". I daresay this would cause problems with programs that want to do raw output, like "vi" and other screen-oriented stuff, because they are expecting to output directly to your terminal, not into a pager. The only other remotely reasonable way you could get between a program's output and your terminal to paginate it is to kludge the terminal driver in the kernel so it would paginate in cooked mode but not in raw mode. (Has anyone been crazy enough to try this?) -- |------------Dan Levy------------| Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an Engihacker @ | vax135}!ttrdc!ttrda!levy | AT&T Computer Systems Division | Disclaimer? Huh? What disclaimer??? |--------Skokie, Illinois--------|
pdg@ihdev.ATT.COM (Joe Isuzu) (10/19/87)
Re: the discussion of putting a pager in the shell. This is not the correct place. The pager belongs in the terminal, and failing that, in a streams module. -- Paul Guthrie Zippy the Pinhead - Zen for the American masses ihnp4!ihdev!pdg -- me.
duncan@comp.vuw.ac.nz (Duncan McEwan) (10/22/87)
In article <1935@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >The only other remotely reasonable way you could get between a program's >output and your terminal to paginate it is to kludge the terminal driver >in the kernel so it would paginate in cooked mode but not in raw mode. >(Has anyone been crazy enough to try this?) Yep. The Z8000 V7 based unix (I think done by Interactive Systems, based on a port initially done at Berkeley) that runs on our old Onyx machine has exactly this feature. Typing stty page stty length 24 will cause the kernel to send a bell to your terminal, and suspend the process after 24 lines have been output without an intervening read(). The feature is disabled when using a program in raw or cbreak mode (I assume automatically by the kernel, rather than every program that switches to raw or cbreak having to turn it off). I don't know about `crazy' either. It seems the only logical place to put such a feature if it's what you want. Not that I ever used it - I prefered the fuller functionality of "more", and I don't think anyone would be crazy enough to try doing regular expression searches in the tty driver :-) Duncan Domain: duncan@comp.vuw.ac.nz Path: ...!uunet!vuwcomp!duncan
simon@its63b.ed.ac.uk (Simon Brown) (10/25/87)
In article <13031@comp.vuw.ac.nz> duncan@comp.vuw.ac.nz (Duncan McEwan) writes: > >Yep. The Z8000 V7 based unix (I think done by Interactive Systems, >based on a port initially done at Berkeley) that runs on our old Onyx >machine has exactly this feature. > > stty page > stty length 24 > >will cause the kernel to send a bell to your terminal, and suspend the process >after 24 lines have been output without an intervening read(). The feature >is disabled when using a program in raw or cbreak mode (I assume automatically >by the kernel, rather than every program that switches to raw or cbreak >having to turn it off). > The tty driver in the UK release of Version 7 had this feature as well, except that you didn't do a "stty page" - you used the ^P key to toggle paging on the fly - much more useful, because you can read a few pages with "paging", and then revert to no-paging when you get bored with the output, leaving it running while you go off for a drink. Needless to say, it doesn't suspend if it prints out 24 (or whatever) lines without doing a read() - it suspends until any character is typed (and throws it away then); this lets you quickly page through something by flicking the space-bar, but without leaving lots of stuff (ie, spaces) in the input stream. Another nice feature it had was "stty width <number>" - the driver had automatic line-wrap built into it. -- -- ---------------------------------- | Simon Brown | UUCP: seismo!mcvax!ukc!{lfcs,its63b}!simon | Department of Computer Science | JANET: simon@uk.ac.ed.{lfcs,its63b} | University of Edinburgh, | ARPA: simon%lfcs.ed.ac.uk@cs.ucl.ac.uk | Scotland, UK. | or simon%its63b.ed.ac.uk@cs.ucl.ac.uk ---------------------------------- or simon%cstvax.ed.ac.uk@cs.ucl.ac.uk "Life's like that, you know"
chris@wacsvax.OZ (chris mcdonald) (10/27/87)
> In article <590@ihdev.ATT.COM> pdg@ihdev.UUCP (Joe Isuzu) writes: > > >Re: the discussion of putting a pager in the shell. This is not the > >correct place. The pager belongs in the terminal, and failing that, in > >a streams module. I think many of you are taking the wrong attitude to this request. The title suggests that the pager should be placed in the shell, but the original article just asked if the author could avoid typing '... | pg' all the time. Yes, a pager does not belong in a shell, yes it may belong in the terminal, but neither of these nagative criticisms are helping. A reasonable solution is to introduce an extra environment variable into a shell, eg PAGER. Then if PAGER is defined, to say 'pg' or 'less' and if stdout (and possibly stderr) of each command in the foreground is not redirected, the *the shell* can arrange these file descriptors to go to $PAGER (or perhaps issue 'stty -page' if installed). I have not added this to any shell, but I can see it as a reasonable addition. -------------------------------------------------------------------------------- Chris McDonald. Department of Computer Science, CSNet: chris@wacsvax.oz University of Western Australia, ARPA: chris%wacsvax.oz@uunet.uu.net Mounts Bay Road, UUCP: ..!uunet!munnari!wacsvax!chris Crawley, Western Australia, 6009. PHONE: (09) 380 2305 OVERSEAS: +61 9 380 2305
snoopy@doghouse.UUCP (10/29/87)
In article <1935@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: > The only other remotely reasonable way you > could get between a program's output and your terminal to paginate it is to > kludge the terminal driver in the kernel so it would paginate in cooked mode > but not in raw mode. (Has anyone been crazy enough to try this?) Actually, you should define another mode, called 'burnt' mode. (very cooked) Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com 68020? Just say NO!
davis%xenurus@gswd-vms.Gould.COM (Tim Davis) (10/29/87)
Has anyone modified tbl to permit > 63 text excursions? I did some preliminary investigations thinking all I had to do was expand some array or define somewhere. Wrong. It seems to take a redesign of a couple of sections. I can see the limitations if I was still running a PDP but if I have 500 meg of memory then who cares? Any suggestions before I do some gutting?
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/30/87)
In article <10048@brl-adm.ARPA> davis%xenurus@gswd-vms.Gould.COM (Tim Davis) writes: >Has anyone modified tbl to permit > 63 text excursions? I started completely overhauling "tbl" and got mostly finished before other projects took precedence. The real constraint lies in troff register names. I was able to extend the number somewhat, but not dramatically. When I finish revamping "tbl", I'll post an announcement; it will be available free to anyone with a DWB 2.0 source license. However, I don't know when that will be!
davis%xenurus@gswd-vms.Gould.COM (Tim Davis) (11/03/87)
Sorry for slipping this request in this discussion. I hit the wrong key at the wrong time. Thanks for the response.