Input Line Editing

Bob Pendleton bpendlet at esunix.UUCP
Tue Jul 19 01:31:36 AEST 1988


>From article <2834 at tekcrl.CRL.TEK.COM>, by eirik at tekcrl.TEK.COM (Eirik Fuller):
> In article <9677 at eddie.MIT.EDU> nessus at wonko.MIT.EDU (Doug Alan) writes:
>>> From: tytso at athena.mit.edu (Theodore Y. Ts'o)
>>> ...
>>
>>Well, that doesn't mean that "ile" is in the wrong place.  "Ile" is in
>>the right place.  What it means is that "ile" should be made smarter
>>for your use.  It should keep track of what programs you fire up and
>>allow you to keep a seperate history buffer for each program.  (If
>>this can't be done efficiently because of the kernal doesn't support
>>this well, then the kernal should be made to support it.)

Ile can already do this, or maybe I should say that the user can
already do this with ile. Just execute you programs under ile. You
automatically get a new history buffer, its a new copy of ile right?
And since ile puts its tty into raw mode the ile that you started out
with will get out of the way. So you have a process tree that looks
like this.

ile
	some-shell 
		ile
			your-program

> 
> Ok, your line editor is going to know all about execing programs.
> Swell.  In what sense won't it be a shell?  It's starting to sound to
> me like you're really saying that shells that only let you edit their
> own command history and not the input to the programs they exec don't
> have full fledged input editing capabilities.

The idea behind ile is to provide a simple, general purpose, tool. This
tool allows me to have a useful and consistent input line editing
interface to most every program I use. It also means that people who
write programs can stop worrying about providing input line editing in
their programs. If people want it, they can just use the ile of their
choice. One of the basic concepts of UNIX as I learned it, was to
provide tools that could be used together by the user to solve the
users problem. Yet, people want to turn ile into a shell. ile offers a
technique for REMOVING input editing from most all programs, including
shells, thus providing the user more control over their environment,
and allowing the programmer to write simpler programs.


> I realize that there are wrinkles to be ironed out in building a
...

> Gee, this fictional shell-editor is beginning to sound more and more
> like a window manager.  
...

Why not try to avoid the tendency to complicate simple ideas? I've now
learned enough about UNIX to believe that I can write a psuedo device
driver that will give me the current working directory of a child
process. But, I'm not sure I want to mess things up that badly.

			Bob P.

-- 
Bob Pendleton @ Evans & Sutherland
UUCP Address:  {decvax,ucbvax,allegra}!decwrl!esunix!bpendlet
Alternate:     utah-cs!esunix!bpendlet
        I am solely responsible for what I say.



More information about the Comp.unix.wizards mailing list