Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!boulder!sunybcs!rutgers!okstate!gregg From: gregg@a.cs.okstate.edu (Gregg Wonderly) Newsgroups: comp.unix.wizards Subject: Re: Input Line Editing Message-ID: <3709@okstate.UUCP> Date: 14 Jul 88 19:33:17 GMT References: <9671@eddie.MIT.EDU> Organization: Oklahoma State Univ., Stillwater Lines: 37 From article <9671@eddie.MIT.EDU>, by nessus@wonko.MIT.EDU (Doug Alan): > In article <10443@ulysses.homer.nj.att.com> > cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes: > >> In article <9666@eddie.MIT.EDU>, nessus@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@A.CS.OKSTATE.EDU