$Id: README,v 2.5 90/08/26 11:31:46 sw Exp $

This is a line discipline that implements input history management.  It
was written originally by Lyle Rains of Atari for RT-11, ported by Dave
Sheppard of Atari to Xenix/386, and ported by Peter Grandi to System
V/386 3.2, as well as _much_ cleaned up and modified.

This README file has been written entirely by Peter Grandi, and so
are all the comments herein.

First of all, while I think this is a very useful driver, and though I
have struggled a lot to make it more like I would have done it, I have
not substantially changed it, even if there are a series of things that
I would have done very differently.

The current advantages of CLED are:

    * It is fully kernel resident, and will keep in the history buffer
    all input, by whatever program.  There is no need to add an
    inefficient raw or cbreak mode library to each program or to hack
    with ptys to have history processing.

    * It is quite fast, and surely has less overhead than other input
    history mechanisms.

    * It can be easily ported to different types of UNIX, and will work
    virtually unchanged on any System V (or V7) derivative.

    * It will get out of the way when not needed, e.g.  for raw or
    cbreak input.

    * It is free.

The disadvantages are:

    * The history mechanism is pretty simple; there are no pattern
    searches, for example.  This is probably a feature.

    * It occupies wired down kernel space.  This is probably a feature,
    because any other interactive history mechanism would probably cost
    vastly more in both space and time overheads.

    * It is not easily extensible, as it is linked with the kernel.
    Again, this is probably a feature.

    * There is no command or file name completion.  This can be
    efficiently implemented by any interested program on top of CLED by
    using the VEOL2 character as trigger.

There are some things that I would have done differently:

    * Design and coding are often quite opaque, and source and object
    sizes too large (4000 lines!).  Cleverer design and coding would
    probably shrink both substantially.

    * CLED is piggybacked onto line discipline 0; it should be
    standalone, to allow for getting rid of the standard line discipline
    completely.

    * Buffers should have been stolen from the buffer cache, instead of
    statically allocated (sptalloc() is no help because of its
    impossibly large granularity).

    * Currently when the user logs out the history is not cleared,
    because technically the tty device is not closed.  This is a
    security hazard, even if not as bad as it looks, because CLED
    disables itself during not echoed or raw input, so that passwords
    are not recorded (passwords passed as arguments to a command are a
    security hazard anyhow).

    * Saving, resetting, and restoring the current history buffer should
    therefore become better supported.

    * The ioctl(2) codes should allow setting key bindings and terminal
    capabilities independently.  In general the ioctl(2) interface is
    quite clumsy.

    * The scled(1) command should be completely rewritten.

There are also a few known problems, but they are usually not mistakes
but rather compromises (e.g.  when inserting tabs in the middle of the
line, the check on line length is circumvented).  Surely there are also
lots of real bugs.

To install CLED, have a look at the "Makefile" (should be ok on most any
UNIX), and at files "cled.h" and "space.c".  It is suggested that you do
not change the configuration options at the top of "cled.h"; not only I
have not tested other configurations, but enabling the most
sophisticated options of CLED substantially enlarges it.  In particular,
unless you know better, do not enable SPTALLOC.

As to the buffer sizes, I think the ones given are OK for most anybody;
note that CLED will not allow you to type a line longer than the current
screen size, so the MAXLINE parameter is really the maximum number of
columns on a terminal, and 132 is therefore sufficient.  As to
MAXPROMPT, I hope you do not use garish long prompts...  In any case
this is the number of characters remembered in the prompt, not its
maximum size.