Input Line Editing

[Gregg Wonderly]

>From article <9671 at eddie.MIT.EDU>, by nessus at wonko.MIT.EDU (Doug Alan):
> In article <10443 at ulysses.homer.nj.att.com>
> cjc at ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: 
> 
>> In article <9666 at eddie.MIT.EDU>, nessus at wonko.mit.edu.UUCP writes:
> 
>> > Putting line editing in the shell is wrong, because it should work in
>> > all programs and be consistent.  Putting it in the kernal is gross.
>> > Thus, the right place to put it is precisely where Bob Pendleton wants
>> > to put it -- in a process which gets input from the user and feeds
>> > edited input to the user's other programs.  [...]
> 
>> You are assuming that
>> 	a) _everyone_ wants line editing in _every_ program
>> 		what about the built in editors on the
>> 		layers and NeWS windowing systems?
> 
> I *do* want editing in *every* program (that takes input as command
> lines).  If someone else doesn't want editing, they don't have to use
> it.  No one is forcing anyone to type the editing control characters.

I just solved that problem here by writing a KSH style history and
command line editor subroutine that is called gets().  Now is just
link it into all of my personal tools (including GOSH, my shell) and
I have consistant editing.  Each application can have it's own history
file, or they can share one.  This routine knows when stdin is not
a TTY and switches to normal gets() operation so that you can still
use < redirection and not worry about lots of overhead, or interpretation
of input.

Is this along the lines of what you want?

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP:      {cbosgd, ihnp4, rutgers}!okstate!gregg
Internet:  gregg at A.CS.OKSTATE.EDU