Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!jade!violet.berkeley.edu!mwm
From: mwm@violet.berkeley.edu (Mike Meyer)
Newsgroups: comp.sys.amiga
Subject: Proposal for an Amiga Shell
Message-ID: <2077@jade.BERKELEY.EDU>
Date: Fri, 2-Jan-87 16:28:16 EST
Article-I.D.: jade.2077
Posted: Fri Jan  2 16:28:16 1987
Date-Received: Sat, 3-Jan-87 07:39:58 EST
Sender: usenet@jade.BERKELEY.EDU
Reply-To: mwm@violet.berkeley.edu(Mike Meyer)
Organization: University of California, Berkeley
Lines: 412
Keywords: Amiga shell cli draft

As promised, here's a suggestion on what I think we could - and
probably should - do for a shell on the Amiga. I realized about the
time that I started writing that this would be a suitable paper for
submission to SIGSMall/SIGPC, and so made it non-Amiga-specific.

Any comments, suggestions, or proposed changes would be greatly
appreciated.

	<mike


DRAFT								DRAFT

		A Shell for Modern Personal Computers

Abstract

Over the last five years, the average personal computer has changed
radically in both power and typical peripherals. The command
interpreters on these machines have not changed to reflect this. The
following paper describes a command interpreter designed for a modern
personal computer, with a high speed 16/32 bit processor, a megabyte
or more of memory, a medium resolution bitmapped display, and a
pointing device.


Introduction

In the last four or five years, personal computers have grown
radically. The typical personal computer today has a CPU as powerful
as a mini or super-mini of five years ago, a megabyte or more of
memory, a bitmapped display with enough resolution to display text
in graphics mode, and some form of pointing device, usually a mouse.
Such machines are now widely available, for prices that place them
squarely in the home computer market.

Meanwhile, the command interpreters, henceforth called shells, for
these machines have not changed noticeably. They are line at a time
command plus arguments processors that have been in use since the
introduction of interactive computing. A few exceptional computers use
the Xerox "desk top" paradigm, with icons to represent programs and
files, and point-and-click to invoke them. While radically different
from earlier command interpreters, these interfaces tend to be clumsy,
and avoided by the experienced user.

The following paper presents a description of a shell called ms,
designed for a modern personal computer. Ms is not meant to be a
radical departure from typical line-oriented shells, but an
enhancement of such shells to use the capabilities of modern personal
computers.  The graphics and windowing capabilities of such systems
are used to keep different ms dialogues separated. The abundant memory
is used to allow reuse of commands and their output. The CPU power of
the machine is used for interactive help and user-level customization.

The paper is divided into two further parts. The first part presents
the ms windows as seen by the user, describing each window and its
uses.  The second part describes the intended customization features
of ms, and touches briefly on the builtin commands of ms.


The User Interface

When running, ms normally has three windows open, the input window,
the history window, and the output window. In addition, at various
times ms can open scrollable output windows, completion windows, and
help windows.  Each of these windows will be described in turn,
along with their interactions with other windows.

The input window contains the command line currently under
construction.  It is the only window that accepts text input or
allows text editing. In normal use, the user types a command into this
window, then hits return to issue the command to the system. Normal
inline editing is supported, as well as some mouse-based editing.
There are other methods for inserting text into this window, and these
will be discussed later.

The history window displays the commands most recently issued by the
user. Whenever a new command is issued, it is appended to the end of
the history window. The history window saves some user-specified
number of commands, and allows the user to scroll forwards and
backwards over them.  The primary use of the history window is in
rerunning commands, or slightly modified commands. To do this, the
user clicks on the command line to be rerun to insert it into the
input window as if the user had typed it, where it may be edited.
Double-clicking will insert the chosen command into the input buffer
followed by a return, which causes it to be run without further user
action.

The output window displays the last few lines of output from the user
commands. The output starts with a a flag line plus the command line,
then the output from the command. Further commands merely append to
this output, and the results scroll out the top of the window. While
there is no way to recover lines that have scrolled out the top of the
window, text can be copied from the output window into the input
window in exactly the same manner as it can be copied from the history
window.

A scrollable output window contains all the output from the last
command run. Unlike a standard output window, no output from commands
other than the last one run is available. However, all the output from
that command is available, whether it fits in the window or not. The
scroll bar needed to provide this capability is what gives this window
with its name. Since the contents of this window are destroyed with
each new command, a facility to save it for later use is provided.
Finally, the ability to copy text from the scrollable output window to
the input window is supported exactly as it is in the history window.

Each of the above three windows (history, output and scrollable
output) also allow the selection of sets of lines. These lines can be
copied into the input window and run as a group. If the system
supports a method for running programs to exchange data - a
"clipboard" or "system shelf" - these lines can also be copied to
that. Of course, lines can be copied from the clipboard to the input
window.

Completion windows provide an easy way for the user to finish typing
commands or arguments ("words") when the exact spelling of the word is
unknown. The user types a key indicating that the word is done, or
asking for completion help. The system then determines which words are
valid in the context of the current line, and opens a window listing
all those words. The user then clicks on the word desired, it is
entered in the input window, and the completion window closes. If
multiple instances of the word being completed are allowed, the user
may select multiple words, then indicate that the list is complete.
All words selected are then entered into the command line.

Help windows provide a brief description of the valid inputs in the
current context. For instance, in the input window, a list of which
characters cause completion might be provided. Help windows provide no
way of copying text to the input window, but can be saved like
scrollable output windows.


User Customization

The amount of CPU dedicated to a single user on a modern personal
computer allows for levels of customization beyond what is ordinarily
available. Indeed, the customization described here provides more than
just customization; it allows users to add new commands in such a way
that the arguments are consistent with already existing commands,
regardless of the interface  provided by the command.

The first level of customization is the initialization file for ms. It
allows users to set internal ms variables. These include four
characters for invoking autocompletion, the two command terminators,
and a list of directories to search for commands (the path). The four
completion characters are:

	- complete argument or command name, usually space.
	- list completions for above, usually tab.
	- complete keyword for argument, usually the equal sign.
	- list completions for above, usually question mark.

When pressed, each of the above attempts to complete the word being
typed, possibly including expanding regular expressions to lists of
words. If there is more than one expansion, the two complete
characters expand to the mutual prefix of all possible completions,
then emit a bell to inform the user that the result is not complete.
If there is no match for the word being typed, a bell is emitted. The
two "list completion" characters open a completion window with all
possible completions, and allow the user to select completions as
described above. If there is no match at all, the completion window
contains the string "no possible completion."

The two command terminators are usually return, for completing the
current command line and submitting it; and semicolon, for completing
the current command line and then starting another in the same input
window. Multiple command lines so built will be submitted separately
to be run, however. When either of these is typed, the user is
prompted for any required arguments that have not been supplied.

The path variables contains a list of directories to be searched for
commands that ms will recognize as external commands. The directory
"." will be recognized as the working directory of ms whenever a
command is issued. In each directory it will also look for a file
named "ms.description" which describes, and possibly customizes, the
argument list to each command.

The "ms.description" file contains a series of command descriptors.
Each command descriptor contains a name descriptor possibly followed
by a list of argument descriptors. The name descriptor gives the word
the user types to issue the command and the string actually issued to
run the command. Each argument descriptor gives the name of the
argument, whether it is required, indicators whether it should be
checked for regular expressions and whether this argument can occur
more than once, and the string actually issued for this argument.

The name descriptor takes one of three forms. It is either:

	ignore	<names>
	command	<name>	alias	<other name>
	command <name>	[is	<string to run command>]

The strings in angle brackets denote non-terminals, provided by the
users. The strings in square brackets are optional. The first form
causes ms to ignore the <names> listed even if the current directory
contains them. "ms.description" is ignored by default in any case.

The "alias" form is complete in and of itself, and causes <name> to be
an alias for <other name>. The builtin command "alias <name> <other
name>" can also be used for this function.

The second form starts a full command description. <name> is the
command the user types to issue the command. <string to run command>
is the string that is used in place of the command. If the "is" part
of this statement is missing, the string defaults to <name>. The
primary use of the "is" facility is to hide interpreters from the
user. For instance, if "ar" is to be run by a basic interpreter, the
command line might be:

	ar is	basic ar

to invoke basic first.

The argument descriptors have two forms:

	required <name> [keyword [<string>]] [expand [single] <what>] [repeated]
	optional <name> [keyword [<string>]] [expand [single] <what>] [repeated]

The major difference between them is that the arguments marked
"required" are required, and will be prompted for when a command
termination character is entered if the user hasn't supplied them. The
arguments are normally issued in the order they occur in the
description file, and are assumed to be entered in that order unless
keywords are supplied.

For example, suppose the "copy" command has the following entry:

	command		copy
	required	from
	required	to

Then the command "copy from_file to_file" would copy from_file to
to_file. The following commands would behave exactly the same, though:
"copy from=from_file to=to_file", "copy to=to_file from=from_file". In
the latter case, ms would reorder the arguments to match the
description file. In addition, if the user forgets an argument, then
they will be prompted for them after the enter a command terminator,
like so:

	display				comment
	-----------------------------------------------------------------
	copy				user types copy followed by a
						command terminator
	copy from=			system prompts for first argument
	copy from=from_file		user types from file name
	copy from=from_file to=		user types command or argument
						terminator
	copy from=from_file to=to_file	user types to file name

Of course, if either argument has been entered (i.e., "copy from_file",
"copy from=from_file" or "copy to=to_file") then it will not be
prompted for.

The "keyword" part of the statement specifies that a keyword must be
provided when the command is issued. The <string> specifies the exact
syntax of the string. If it is missing, then the issued form is the
name provided for the argument, a space, and the string provided by
the user for the argument. So if copys from argument entry had read
"required from keyword", and the user typed "copy from_file to_file",
the actual string used for the from argument would be "from
from_file".

If the string is present, it must be surrounded by either single or
double quotes. Special characters (return, newline, quotes themselves)
may be inserted into the string with an escape sequence. These
sequences are two characters long, and the first character is always
backslash ("\"). The second character is interpreted as so:

	n		newline
	r		carriage return
	b		backspace
	t		tab
	f		form feed
	s		string provided by user as argument

Any other characters following a backslash are inserted as is into the
string. Most notably, quotes and the backslash character can be
inserted in this way.

Suppose, for instance, that the copy command required that its
arguments be presented with the keywords followed by an equals sign
and the file name. Then the copy command could be described as

	command		copy
	required	from keyword "from=\s"
	required	to keyword "to=\s"

and it would appear to the user exactly as the previous version did.

The expand part of the descriptor causes this argument to be expanded
by regular expressions in the user-supplied string. The regular
expressions characters supported are:

	?		match any single character
	*		match zero or more arbitrary characters.

The keyword "single" is provided if this argument must match only a
single word. The <what> part describes what the regular expression
should be expanded against. This could any of the keywords "file" to
cause matching against files, "process" to match against processes,
"device" to match against devices, "host" to match against other
machines on a local network. Plural forms of these words are also
recognized.  In addition, a parenthesized list of words that are to be
matched against, separated by spaces; or an indicator that such a list
should come from an external file, can be used.

For example, to allow the copy command to expand against files, but
still require only a single file for each argument, its descriptor
would be:

	command		copy
	required	from expand single files
	required	to expand single files

The delete command, on the other hand, accepts multiple files, and so
may be represented as:

	command		delete
	required	file expand files

To allow an argument that can expand to multiple files.

The repeated keyword may be added to optional arguments to show
that it may occur zero or more times. If added to a required argument,
then that argument must occur one or more times.  Since delete accepts
multiple arguments, each of which may be a pattern, its command
descriptor could reflect this as:

	command		delete
	required	file expand files repeated

To provide for flag arguments, the optional command recognizes a
special form for <name>. If <name> is quoted, by either single or
double quotes, then it is assumed to be the text for a flag that the
user may enter. If no keyword is present, the it is copied as is to
the command to be issued. Otherwise, the keyword string must be
present, and will be copied as is instead of the keyword. Neither the
expand keyword nor the repeated keyword is allowed in this case.

For example, suppose that the delete command looked for the string
"opt a" after its arguments to allow recursive deletion of a tree. To
provide this facility, but make make the keyword "tree", the
descriptor for copy would be:

	command		delete
	required	file expand files repeated
	optional	"tree" keyword "opt a"

In processing user input, any word on the input line after all the
arguments that ms knows about have been processed will be passed as
is. Thus, if no argument processing is to be done at all for the
command echo, it can be completely specified by:

	command 	echo

Finally, as each directory is scanned, an entry of the form "command
<name>" is built for every command encountered. Thus, all commands in
the path, except those in ".", will be accessible from ms's internal
tables.

The above facilities are designed to allow commands that may not be
consistent with the current set to be added, and made consistent.
While not every possible command syntax can be dealt with, those that
cannot should be rare in practice. Should more power be needed, it
would probably be best to provide a template macro processor instead
of a description language.  In the process of providing this facility,
the user has been given much power to customize commands without
changing the sources. Indeed, the above may be to ambitious for
current personal computers. Should that be the case, a few years will
see the problem solved.


Some Final Comments

First, it should be noted that the two pieces of this description can
be separated, and, have been. There are tools - including shells -
that support multiple dialogues in separate windows. There are also
shells that support command description languages and argument
completion. I know of no shell that provides facilities for
customizing commands as described here, nor do I know of a shell that
provides both command description and multiple output windows.

Second, peoples reactions to pointing devices vary greatly from
individual to individual. Some people find them useful, and
dislike going back to a keyboard. Others dislike pointing devices, and
seldom use them if provides. Some people have no problem switching
back and forth between a keyboard and a pointing device, and do so
frequently. Others tend to dislike such switching, and tend to stay
with one or the other as long as possible. To provide for a variety of
tastes, keyboard "shortcuts" to some or all the mouse driven
features should be provided. For instance, hitting return when a
completion window appears to indicate that all completions should be
used would be one such feature. Likewise, command characters to scroll
the history list through the input window could be provided.

Third, this is obviously not the only approach to using the power of
the modern personal computer to provide a better, more usable, shell.
For instance, at least one such interface lists files on the screen,
and allows the user to select files and then run commands with the
mouse. Here, the shell is almost completely mouse driven, whereas ms
is almost completely keyboard driven. I am sure that other approaches
exist, and hope they will be investigated.

Finally, this paper does not describe an existing shell, or even one
that is being planned. The purpose of the paper is to show what could
be done, and hopefully cause people to rethink their ideas about what
a shell should be and do. Months of debating about which features
should be provided by a shell led me to realize that most people,
myself included, had not thought about the facilities that could be
provided on a modern personal computer. A paper to shake people out of
this rut seemed to be in order.