Path: utzoo!utgpu!watmath!att!pacbell!ames!rex!ginosko!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: Strangeness in shell
Message-ID: <10680@smoke.BRL.MIL>
Date: 7 Aug 89 19:51:56 GMT
References: <432@mccc.UUCP> <9700009@osiris.cso.uiuc.edu> <2277@auspex.auspex.com> <10639@smoke.BRL.MIL> <5404@ficc.uu.net> <9729@alice.UUCP> <10665@smoke.BRL.MIL> <9747@alice.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <9747@alice.UUCP> debra@alice.UUCP () writes:
>I don't know the 5620 firmware, only Rob's "mux" interface.
>On the 630 I cannot type a command, say "ls file", then click before the
>"f", type "-l", click at the end of the line, press return and have
>the shell execute "ls -l file". That's what I mean by local command line
>editing, and that's not possible on the 630 because it operates in full
>duplex.

On the 630, you can perform a similar local edit, snarf the edited line
(newline not yet having been typed), type line-erase so that UNIX doesn't
see the characters already typed, then send the snarfed edited line.
"mux" maintains a record of the last-output point and doesn't send
anything at all to UNIX until a newline is typed somewhere beyond the
last-output point, which is why you don't have to clear the already-typed
stuff out of the UNIX terminal handler before sending the revised input
line when using "mux"; otherwise the operations are essentially the same.
There's nothing I know of about the 630 that prevents "mux" from being
implemented for it as well as the 5620.  It should be a fairly easy
porting job, the 630 being basically an augmented 5620 based on an MC68xxx
(like the Blit) instead of a WE32xxx.