Type-ahead in unix
Fred Stluka
(Ronald S H Khoo) writes (as part of an ongoing diuscussion in
comp.unix.questions about how to best echo typeahead, for the
sake of you comp.sys.apollo guys to which I am cross-posting):
> Can someone explain how Rob Pike's Plan 9 stuff does *both* echoing
> immediately *and* rearranging the display so that the output doesn't
> have its appearance ruined? Sounds like the best of both worlds to me ..
Not exactly an answer to Ronald's question, but along the same lines...
The Apollo DOMAIN systems (running Unix) have a nice solution to this.
The window is divided into 2 panes with a horizontal line between them.
The top pane shows the command lines you have typed intermixed with the
lines of output generated, in the usual style of a Unix system on which
you have done no typeahead. The bottom pane is an editor window into
which you can type commands.
Ordinarily the bottom pane is one line long, and when you hit return the
command you typed scrolls into the top pane. However, if your previous
command has not yet completed, then the new command stays in the lower
pane which grows one line longer so that you can continue to enter more
commands. Each time you hit return, you get another line in the bottom
pane. Each time a command completes, the top line of the bottom pane
scrolls into the top pane and starts being processed. You get to see all
of your typeahead, as well as a clear indicator of which commands have
been processed so far. Also, the resulting top window shows a natural
mix of input and output, with nothing scrambled.
If you get ahead of the computer to the point that there are several
command lines waiting to be processed, you can scroll back up to those
lines and edit them, without affecting the lines which follow. You can
cause this to happen intentionally, by hitting the HOLD key to direct
the computer to stop processing commands (until you hit HOLD again),
if you want to compose a series of commands before allowing any of them
to be processed.
You can also cut and paste, from any window including the output pane,
into any window including the input pane. This makes it very easy to
write your own command line recall mechanism, by defining a key to
search backwards through the output pane for prompts and to copying
the rest of the line you choose (the command) into the input pane.
Unfortunately, HP has bought Apollo, and seems to plan to drop the
DOMAIN Display Manager. Hopefully, someone else will pick up on the
same idea, and it will become prevalent in Unix systems.
--Fred
--
Fred Stluka Internet: stl...@software.org
Software Productivity Consortium UUNET: ...!uunet!software!stluka
2214 Rock Hill Rd, Herndon VA 22070 USA
Rob McMahon
>The Apollo DOMAIN systems (running Unix) have a nice solution to this.
I've used it. I *hated* it. You keep having to scan up and down between the
commands you're typing and their results. That and the abysmal reaction when
you enter and leave a cbreak/curses application like an editor, or less: when
I leave less, I want the last thing I've been looking at to still be on the
screen, thanks.
Yeuch.
Rob
--
UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037
JANET: cu...@uk.ac.warwick INET: cu...@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England
Jim Rees
[ about the Apollo DM and its pads ]
I've used it. I *hated* it. You keep having to scan up and down between the
commands you're typing and their results. That and the abysmal reaction when
you enter and leave a cbreak/curses application like an editor, or less: when
I leave less, I want the last thing I've been looking at to still be on the
screen, thanks.
You hated it because you're still thinking of it as a vt100 emulator. DM
pads are not vt100s. If you want a vt100, start one up -- I recommend
xterm.
Andy Tosswill
>From: Jim Rees <agate!bionet!uwm.edu!rpi!zaphod.mps.ohio-state.edu!caen!umich!terminator!dabo.citi.umich.edu!re...@ucbvax.berkeley.edu>
>Subject: Re: Type-ahead in unix
>To: apo...@umix.cc.umich.edu
>
[...]
>You hated it because you're still thinking of it as a vt100 emulator. DM
>pads are not vt100s. If you want a vt100, start one up -- I recommend
>xterm.
Speaking of vt100 emulation: when I try to use the csh "filec"
facility on an Apollo, the command line is not redisplayed correctly:
When I type ^D:
hubble 1% ls .l^D
.login .logout
hubble 1% <- No redisplay, should be ls .l
^^^^^
or <ESC>:
hubble 1% ls .a<ESC>
hubble 1% ls ias <- Incorrect redisplay, should be ls .alias
^^^^^
However, the command line buffer is correct, as typing <return>
issues the correct command:
hubble 1% ls ias
.alias
hubble 2%
This happens on both vt100 emulation run from a DM pad, and also
with telnet logins using vt100 emulation. I have checked my stty
settings and they are the same as on some other machines on which filec
works correctly for me (e.g., Sun and SGI).
Any suggestions or advice? Thanks.
-- Andy
--------
Andy Tosswill (atos...@bbn.com)
BBN Systems and Technologies, Advanced Simulation
14100 SE 36th Street, Bellevue, WA 98006 USA
Phone: 206 746 6800 Fax: 206 746 1335
Rob McMahon
writes:
>[ about the Apollo DM and its pads ]
>pads are not vt100s. If you want a vt100, start one up -- I recommend xterm.
But the article I was replying to was extolling the virtues of the DM pad type
of interface. Okay, so I can turn it off, and make it behave like any other
Unix, but that's not the point. The old ICL Perq has this same two-window
approach, and I've used it under Apollo's Domain/OS (?), and under their Unix,
and I think it's a pain.
On a constructive note, I used to quite like the Burroughs MCP/CANDE approach
of holding up output while you were half-way through an input line, allowing
you to see and edit the line you were typing, and then releasing it when you
hit return, until you had typed the first character of the next line. On the
whole, though, with ^R, and with automatic reprint when you try to delete a
character that's before a chunk of output, I prefer the Unix approach.
Kee Hinckley
>I've used it. I *hated* it. You keep having to scan up and down between the
>commands you're typing and their results. That and the abysmal reaction when
>you enter and leave a cbreak/curses application like an editor, or less: when
>I leave less, I want the last thing I've been looking at to still be on the
>screen, thanks.
Have you used an xterm? They don't leave vi sessions sitting on the screen
after you use them - you go back to the transcript instead. In fact most
Mac terminal emulators do this too.
There is the problem with pads that they don't do vt100 emulator, so
they have to start a separate application for curses. So you don't see
the history even if you don't clear the screen. But that's a misfeature
of the particular implementation - when Apollo made pads they didn't
realize that people were going to treat workstations as though they
were just a way of having lots of terminals with one keyboard.
--
Alfalfa Software, Inc. | Poste: The EMail for Unix
naz...@alfalfa.com | Send Anything... Anywhere
617/646-7703 (voice/fax) | in...@alfalfa.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Ashley Aitken
From article <+G-_A&=@warwick.ac.uk>, by cu...@warwick.ac.uk (Rob McMahon):
> I've used it. I *hated* it. You keep having to scan up and down between the
> commands you're typing and their results.
Only initially when the output pad is empty, eventually the output is just
above the input pad.
On the other hand, using DM you always know where you input line is, you never
need to scan up and down a window, its always at the bottom in the input pad.
> That and the abysmal reaction when
> you enter and leave a cbreak/curses application like an editor, or less:
True, the cbreak/curses application startup has a slight pause. However, it was
my understanding that Apollo expected you to use their editor, and that the DM
was optimized for this. In fact, I think starting a DM editor session is faster
than starting vi or emacs in an xterm.
> When
> I leave less, I want the last thing I've been looking at to still be on the
> screen, thanks.
But you've got it completely wrong. DM does away completely with the need for
a tool such as less (or more). If you want to scroll through (forwards, and
backwards, with searching etc) a file you can just cat it (with the DM Hold
function on). Even better just pop it up on the screen in another window (DM
is optimized for that, remember) and scroll through it (there are even some
keys especially for that!).
> Yeuch.
Take a closer look, and work with it for a while. It's rather tasty in fact.
(Of course there is room for improvement ...)
The DM is a *real* different alternative to multiple terminal sessions and it
deserves a lot more consideration and attention than it gets.
Chow now brown cow,
Ashley Aitken.
--
E-MAIL : ash...@spectrum.cs.unsw.oz.au ARNNet
POSTAL :
Academic Address: Residential Address:
School of EE and CS, (Mech Eng Rm 447) c/o Basser College, (Flat 7A)
University of New South Wales, The Kensington Colleges,
Box 1,PO KENSINGTON,N.S.W.,2033. Box 24,PO KENSINGTON,N.S.W,2033.
AUSTRALIA. AUSTRALIA
Ph. (02) 697-5378 Fx. (02) 662-2087 Ph. (02) 663-8117
System Admin (Mike Peterson)
> Speaking of vt100 emulation: when I try to use the csh "filec"
"Filec" is broken (and has always been broken at SR10), though HPollo
claims that it works as of SR10.2 - well, it does work, but you have to
use the "rprnt" key (^R by default, but we change it to ^_ since ^R is
used to redraw the screen in vi on terminals where ^L is used for cursor
right) to see the completed line. We have given up on this being fixed,
and don't use it, though many users want it (must be "performing to
specification" :-) ). I have an APR from SR10.0 on this one.
--
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: sys...@alchemy.chem.utoronto.ca
Tel: (416) 978-7094 Fax: (416) 978-8775
Rob McMahon
Hinckley) writes:
>Have you used an xterm?
Yup, I use them all the time. *Our* xterms don't do that, that was the very
first thing I disabled.
Andy Tosswill
Thanks to those who responded to my query on csh "filec"
Domain/OS. As I suspected, it's broken and probably won't be fixed any
time soon.
I have previously used the ^R (rprnt) work-around that several
people suggested, but I was hoping that there was a fix that would make
filec work correctly.
Richard Tobin
>On a constructive note, I used to quite like the Burroughs MCP/CANDE approach
>of holding up output while you were half-way through an input line, allowing
>you to see and edit the line you were typing, and then releasing it when you
>hit return, until you had typed the first character of the next line.
This can be a pain if you've inadvertently typed something - you're
left wondering where the output's gone. It's particularly annoying
if you make the mistake RSX-11 made and don't release the output if
the user deletes the input. It would also be good to have a way of
releasing the output without hitting return or losing the input.
-- Richard
--
Richard Tobin, JANET: R.T...@uk.ac.ed
AI Applications Institute, ARPA: R.Tobin%uk.a...@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
Barry Margolin
>In article <-Q=_Y$_@warwick.ac.uk> cu...@warwick.ac.uk (Rob McMahon) writes:
>>On a constructive note, I used to quite like the Burroughs MCP/CANDE approach
>>of holding up output while you were half-way through an input line
>left wondering where the output's gone.
Multics also has this option in its tty driver (actually, it's implemented
in the front-end, so it doesn't work for pty's and network terminals, or
when you're doing character-at-a-time I/O). It includes a timeout, so
accidentally hitting a key doesn't stop output forever.
--
Barry Margolin, Thinking Machines Corp.
bar...@think.com
{uunet,harvard}!think!barmar