shepperd@dms.UUCP (Dave Shepperd) (05/10/89)
I'm looking for a few users willing to try out my command line editor
(beta test it) before I post the thing. It works quite well here with
VT100 (ANSI) compatible terminals directly connected via dumb serial
ports, the system console (works especialy well if the keys are mapped
to match those of a VT100), X11 window system servers running xterm and
VT100's telnet'd into the system via terminal servers (other Xenix
systems, actually).
The purpose of the beta test is to determine:
1) if there's some bugs remaining in the package.
2) if it'll work at all on terminals connected via "smart"
serial I/O controllers (I don't have any yet).
3) if it bogs down (noticeably) on heavily loaded systems.
4) if the system bogs down because of it. (I haven't noticed either
case on any of our lightly loaded systems).
5) if installation is as much a pain in the a*s as I think it might
be for people and how I can fix that.
6) it'll work with flavors of pty's other than those supplied by SCO
(Excelan for example).
Minimum System requirements to use this editor:
1) Xenix/386 2.3.1
2) Xenix/386 develpoment system (2.2 dev sys will work, I think).
3) The link kit must be installed.
4) Stable system configuration since you'll need to edit some
files that config makes (and remakes with each change to
/usr/sys/conf/master)
5) willingness to edit system configuration files and re-link the
kernel.
6) VT100 terminals (or compatibles) connected either directly or
through terminal servers or X window system servers running xterm.
Sorry, but the editor knows deep in its bones that it is talking to a
ANSI terminal (VT100) and this cannot easily be changed. Termcaps is not
available to kernel code. I made no provisions for and took no precautions
against using it with '286 code, so although it MAY be possible to get it to
work on a Xenix/286 system (I doubt it), I have no plans to do so.
First the features (or bugs or warts depending on your point of view):
There are 16 editor primatives which are:
toggle insert/overstrike mode
skip to beginning of line
skip to end of line
delete "word" to left of cursor
delete "word" to right of cursor
delete from cursor to beginning of line
delete from cursor to end of line
move cursor left one char
move cursor right one char
delete char to left of cursor
delete char under cursor
repaint line
recall previous command
recall next command
find (next) matching command
newline
Each primative is (optionally) assigned to a control key and/or a
terminal function key (such as up-arrow or PF4). You probably won't like
the defaults that I have chosen for these (I'm a VMS/TPU user),
so there's a mechanism for you to assign them however you like.
Command history is explained in more detail later in this message.
Any key not defined to one of those primatives (except null, VINTR and
VQUIT), is inserted into the command line at the cursor.
Briefly, how it interfaces the user with the system:
This editor (I call it CLED) is actually two separate and somewhat
independent programs. One is a line discipline (CLE) and the other is a
character device (CLED). The device has ioctl functions defined that can
be used to setup various things in the editor such as key functions and
defaults but is otherwise unused. The line discipline is the editor. It
can be turned on/off with the stty command and/or ioctl's from within
a running program. It also turns itself off while the terminal is set
to "raw" mode (CLED defines "raw" mode as having any of the tty bits
IECHO, IECHOE, IECHOK or ICANON clear; that is, all four bits must be
set for the CLED to do its work).
Since the editor is implemented as a line discipline, it is not
tied to any particular program or shell. It does not fork a process
nor does it insert an additional layer of processing that isn't already
called for with discipline 0 (if terminal data is to be "cooked", CLED
does the cooking instead of discipline 0). Please note that it does
NOT replace any "off-line" editing that your programs or shells might
have (i.e. the command line editing of csh or ksh will work exactly
the same whether CLED is running or not).
A side note:
I am fully aware that the "line discipline system" of Xenix/Unix is
doomed and is to be replaced with a clearly far superior system known as
streams. I do think, however, that'll probably be a couple of years
before the default terminal I/O (i.e. that used by the login shell)
reverts to using streams (SCO/UNIX 4.0 maybe?). (Spoken with no degree
of authority, but judging from other product timetables coming from SCO,
a slightly higher degree of confidence). Some will say not to use this
because it'll stop working with some future release of the O/S. Judging
from how quickly it was accepted by all the Xenix users here (especially
me), it think it's not such a bad thing to use for as long as it
lasts. [If somebody said to you, "You wanna borrow my Mercedes 550
for free for the next year or two?" would you say, "Nah, someday you'll
come and take it away. Thanks but no thanks". I wouldn't.] Besides,
perhaps by then I will have figured out how to put most of this, if not all,
in a streams module. Or better yet, maybe somebody at SCO will start using
this thing, get hooked on it and will figure out how to make it work
with streams for me. Since I hop from Unix to VMS several times a day
and to MS-DOS a few times a week, I find it REAL handy that they all have
the same "real" command line editing.
Some more niggly details for those really interested:
Characters are escaped with a null instead of discipline 0's '\'. You type
a null character which will open a space under the cursor (prints a ?) and
the next character you type (except null, VQUIT and VINTR) will be inserted
in spot under the cursor. It is not possible to insert a null in the command
line. Sorry about that. Control characters are displayed in inverse video.
and the DEL character is displayed as an inverse video '?'.
Command line history functions:
The history buffer is size COMBUFSZ. It is not dynamically allocated
because there's limited non-paged pool (VMS terminology) and no
process quotas. At this time, I'm not sure how to enforce process
quotas so I just made the buffer size fixed. To save space,
recalled commands entered unchanged are moved to the
head of the buffer as are commands entered that match
existing entries in the history buffer. That is, there won't be
multiple occurances of exactly the same command in the
history buffer. There is one of these buffers assigned
from a pool for each process that establishes a stream
to the terminal. (I.e., you will have a different history
buffer for each application that is forked from the shell).
recall previous command: normally assigned to up-arrow, puts the
next command in the history buffer on the command line
replacing whatever is there. If there are no more lines
in the history buffer (i.e. you scrolled off the top)
a null line will be brought up.
recall next command: normally assigned to down-arrow, puts the
command that followed the one currently on the command
line. This is only useful if you've preceeded it with
some up-arrows, because scrolling off the bottom of the
history buffer results in a blank line.
find (next) matching command: Type some chars on the command line
(such as vi, m or cc), then type the char you've assigned
this primative and CLED will find the most recent command
in the history buffer that matches. If you make no changes
to the command line and type the assigned char again,
CLED will find the next youngest matching command and so on.
It echoes a bell if there are no more matching strings.
Command line prompts (you'll probably have to see this to believe it):
CLED attempts to determine a prompt string by capturing in a buffer
text written to the terminal from the process that last did a
read (this means, unfortuneatly, CLED doesn't "know" about the
first prompt string sent to the terminal after CLED is turned on
and before the first read is issued). The buffer is
sent to the terminal and cleared when a CR or LF is seen.
If a read is issued to the terminal, then the contents of the
prompt buffer are displayed followed by an escape sequence to
erase the display to end of line.
Sometimes it screws up and doesn't get it right, but it is no
worse than the way the system works without it.
The behavior of this discipline will certainly be foreign to any and all
Unix users since it is the only one that I know of that doesn't echo
characters as they are typed. Instead typeahead is saved in a buffer and
echoed only after a read is issued to the terminal (this is the
behaviour of the VMS and MS-DOS terminal drivers). I didn't necessarily
design it this way, but instead it fell out of the cracks due to the
fact that the editor itself runs at task time rather than at interrupt
time and it is responsible for echo. I am not going to change this, it
is not negotiable. You may not like it this way. If you don't, then this
CLED is not for you, please don't use it and please, flames > /dev/null.
This discipline trys to be "helpful" and recognise when your command
line gets messed up by a "broadcast" message. That is some other process
sending some text to your terminal while your typing in a command (or
waiting at a prompt). When this happens, it'll clear the current line,
display the broadcast message and repaint the command line. There's a
1/10 second delay between the broadcast message and repaint. CLED calls
discipline 0 to do all of its output processing. I'd especially like to
know if this "feature" causes more problems than it cures.
Please send E-mail to me if you are interested in trying this. I expect
it'll take a week or two for any and all responses to show up at which
time I'll mail back the necessary files. Our mailer has trouble from
time to time, so a uucp address would be the best if you have one.
--
Dave Shepperd. shepperd@dms.UUCP or weitek!dms!shepperd
Atari Games Corporation, Sycamore Drive, Milpitas CA 95035.
(Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer).