Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!decwrl!labrea!sri-unix!quintus!sun!pitstop!sundc!seismo!uunet!uport!plocher
From: plocher@uport.UUCP (John Plocher)
Newsgroups: comp.unix.wizards
Subject: Re: Input Line Editing
Message-ID: <377@uport.UUCP>
Date: 23 Jul 88 23:37:13 GMT
References: <16456@brl-adm.ARPA> <9666@eddie.MIT.EDU> <9677@eddie.MIT.EDU> <1112@ficc.UUCP> <6339@bloom-beacon.MIT.EDU>
Reply-To: plocher@uport.UUCP (John Plocher)
Organization: Microport Systems, Scotts Valley, CA
Lines: 24

In article <6339@bloom-beacon.MIT.EDU> Theodore Y. Ts'o writes:
> putting the line editor in the shell is the right thing to do.

I've found all three methods (in shell, in kernel, in program) to
be useful at different times.  For the *few* programs that need
special editing (pre-selected defaults, interactive command driven things,
etc) a simple library call to an edit_gets() solves many problems
without making anyone else's programs pay for the feature.

For most of the other interactive editing I do, the shell (ksh) editing
features meet my needs.  If you think about it, the shell has its own set
of library calls to do line editing, so there are only 2 methods :-)

The normal editing that the tty driver does is often enough for
the programs which don't need the complex editing features outlined
by other posters here.

Like most things in the Real World, there isn't always one Right Thing.
It is a Good Idea to provide a method, but let someone else provide policy.
Library calls (or dynamic linkage or configuration thru ioctl()s...) to
set up an editing environment are OK, but don't implement something that
could get in the way of a program which didn't need it.

 -John Plocher