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.
command alias
command [is ]
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 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 to be
an alias for . The builtin command "alias " can also be used for this function.
The second form starts a full command description. is the
command the user types to issue the 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 . 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 [keyword []] [expand [single] ] [repeated]
optional [keyword []] [expand [single] ] [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 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 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 . If 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
" 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.