mwm@violet.berkeley.edu (Mike Meyer) (01/03/87)
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.dillon@CORY.BERKELEY.EDU (Matt Dillon) (01/03/87)
For Sure, it's cute, but not completely practical. Customization Aside, my major complaint about such a system is simply that it's too cluttered. Three windows? One of the several terminal programs I wrote had two windows ... a 'terminal' window and a 'command' window, and I can tell you that I got rather tired of the 'command' window. keywords also slows me down... I don't want to be forced to type long drawn out english keywords for commands. Shell's were never meant to be user friendly. So I think maybe it would make a good idiot-box. As far as I'm concerned it goes into my "It works in Theory, but not in practice" folder. Oh, P.S. I am definately *NOT* saying that my Shell is real, it isn't. I have yet to see any shell that efficiently integrates keyboard, mouse, and graphics screen with the power of shell scripts, aliases, and file/command completion. -Matt
mwm@eris.BERKELEY.EDU (Mike (Don't have strength to leave) Meyer) (01/07/87)
In article <8701031030.AA23133@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > For Sure, it's cute, but not completely practical. Customization >Aside, my major complaint about such a system is simply that it's too >cluttered. Three windows? One of the several terminal programs I wrote >had two windows ... a 'terminal' window and a 'command' window, and I can >tell you that I got rather tired of the 'command' window. Actually, normal use would have two windows - the input window and one of the two flavors of output window. That may be an annoyance; have to try it and see. I can't really see how it would be much worse than say dpaint with the menu/gadget bar. > keywords also slows me down... I don't want to be forced to type >long drawn out english keywords for commands. Shell's were never meant >to be user friendly. That's why the shell will autocomplete keywords for you. Of course, you can also just customize things so you get positional parameters for everything. Even commands that REQUIRE keywords; you'd say: required from keword "from=" in the ms.description file, and the shell would supply the keyword for you. I thought I explained that in the paper. > So I think maybe it would make a good idiot-box. As far as I'm >concerned it goes into my "It works in Theory, but not in practice" folder. Probably correct. I'd like to see people who are doing shells start thinking about such things, though. Zing is the only thing I know of that really tried. Gotta see about getting a copy of it to play with sometime soon. Of course, if I get done with all the other interesting-looking things I want to do, or get motivated, I may sit down and do the thing myself anyway. >Oh, P.S. I am definately *NOT* saying that my Shell is real, it isn't. >I have yet to see any shell that efficiently integrates keyboard, mouse, and >graphics screen with the power of shell scripts, aliases, and file/command >completion. I didn't think your shell did file/command completion. Ms has aliases, and maybe a little better. Shell scripts (even to the level of the v6 shell) it don't got. Gotta consider how to do that kind of thing.... Thanx, <mike
daveh@cbmvax.cbm.UUCP (Dave Haynie) (01/14/87)
> > In article <8701031030.AA23133@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>One of the several terminal programs I wrote >>had two windows ... a 'terminal' window and a 'command' window, and I can >>tell you that I got rather tired of the 'command' window. > > Actually, normal use would have two windows - the input window and one > of the two flavors of output window. That may be an annoyance; have to > try it and see. I can't really see how it would be much worse than say > dpaint with the menu/gadget bar. A good implementation of a two windows scheme would probably work well. The standard shell used on Apollo workstations implements a two window scheme of sorts. Essentially, you've got one input and one output window which together remain a constant size, which you can of course adjust with a mouse. The command window starts out one line long, but grows by one line for each line that hasn't yet been processed by the command processor. There's a ceiling on the amount that the command window can grow by, and the growth space is returned to the output window of the shell as soon as only one line of input remains. This setup lets you get immediate feedback from typeahead without disturbing the output flow (like csh) or stopping the output flow (like CLI). This shell also allows cut and paste within the input window and copying into the paste buffer from the output window, which effectively eliminates the need for any sort of history list (the output window retains a complete transcript of any terminal session, one of the many things you can do with giant, fast hard disks I guess. Not too useful in the case of the basic Amiga, though). -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "You can keep my things, they've come to take me home" -Peter Gabriel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pete@topaz.berkeley.edu (01/19/87)
In his "Proposal for an Amiga Shell", Mike Meyer omitted a little bit of
information. He didn't mention that his basic proposals for the shell's
user interface actually exist already as working features of my own
enhanced CLI "Sili(Con:)". Although I know it's not usually done to
advertise one's own products on the net, I felt that at least I had to
establish Prior Art! In any case Sili(Con:) is shareware, so maybe it's
OK. Mike admits that my program (which I showed him a few weeks before
Christmas) was one of his idea sources. Of course there are many other
suggestions in his paper as well, that aren't yet implemented in any Amiga
program that I know of; I'll try to submit some comments on those later,
when I've thought about it a while.
Having staked my claim, I'd better show some nuggets. Sili(Con:) was
written to give the user a bit more power than the very basic "Glass TTY"
you get with the AmigaDOS CLI. It is a CLI itself -- or Shell if you prefer,
but don't infer any unix-like connotations -- that takes over from the
standard one, popping up its own window, subdivided into two. The bottom
part -- actually a string gadget (sort of) -- is where you enter commands,
just as you would to the old CLI; you have full cursor (and mouse) editing
capabilities here, naturally, until you hit return, when the command is sent
for execution, queued if necessary. Each new command as entered pops up
into the upper "History" window, where it is available for recall at any
time, either by selection with the up and down arrow keys or directly
with the mouse; you can edit a recalled command before re-executing it
if you want. Double-clicking with the mouse executes it immediately. Up
to fifty commands will be kept in the history before the oldest ones are
bumped, but commands that are re-executed without editing are not put in
the list a second time. Output from the commands appears in the original
DOS window (unless it opens one of its own), and you interact with the
command there also, if you need to.
There are other convenience features of course, like being able to push
the Sili(Con:) window out of the way or bring it -- activated -- to
the front with single keystrokes, and direct execution of command script
files. The command format is totally compatible with the standard CLI.
I won't go on in detail here, because I've about covered its relation to
Mike's proposal. Of course I'm working on further versions, and I might
even snitch some ideas from him if I like 'em!
-- Pete Goodeve --
========================================================================
Disclaimer:
I think for once a disclaimer might be appropriate.
"Sili(Con:)" and any other activities or views of mine
apropos the Amiga have no connection with the University
of California, by whom I am currently employed as a
consultant.
=========================================================================mwm@eris.BERKELEY.EDU (Mike Meyer) (01/19/87)
In article <2255@jade.BERKELEY.EDU> pete@topaz.berkeley.edu.UUCP () writes: >In his "Proposal for an Amiga Shell", Mike Meyer omitted a little bit of >information. He didn't mention that his basic proposals for the shell's >user interface actually exist already as working features of my own >enhanced CLI "Sili(Con:)". Although I know it's not usually done to >advertise one's own products on the net, I felt that at least I had to >establish Prior Art! Thanks for giving me warning about this, Pete - it gave me time to think of a proper answer! To wit, I'm going to trace the ideas behind two windows, the input window and the history window (you'll notice they aren't quite the same as your Sili(Con:), though - I split them up into two windows, instead of one window with two panes), by showing where I first saw some of the basic features: Separate input/output: Gosling emacs. " " in windows: UO LISP History: InterLISP click to select, double-click to run: Apple LISA Selectable/editable history: ksh History in a separate window: Me(*) (*) In working on mg, I decided that I wanted to add a shell interface, but in a way that dumb (read: Messy-DOS) machines could do. So I invented an interface with a "submit-to-shell" command that put the output in one buffer, and appended the command to a shell history buffer. I then implemented that for GNU, and gave it to the development group. That was back in August or so. So you see, I can actually prove that Sili(con:) had nothing to do with the ms :-). Of course my reaction was to Sili(con:) was "Gee, that's neat & obvious. Why didn't *I* think of it?" That was one of the things that started me thinking about what you could do if you got SERIOUS about an Amiga shell, and I lifted large parts of the user interface from Pete's work, tweaked a little by all of the above, plus lots of other window-ish things. In any case, I wanna congratulate Pete on creating an AmigaDOS CLI that uses the workstation-like aspects of the machine, as opposed to porting an interface from another, inferior (:-) OS, or making some minor improvements on the supplied CLI. >In any case Sili(Con:) is shareware, so maybe it's >OK. Mike admits that my program (which I showed him a few weeks before >Christmas) was one of his idea sources. Of course there are many other >suggestions in his paper as well, that aren't yet implemented in any Amiga >program that I know of; I'll try to submit some comments on those later, >when I've thought about it a while. Please do. I've already changed the paper to explicitly mention that "there are ~ ALEPHnull sources for those ideas, so they won't be mentioned" (the custimization stuff is as messy, covering things from Nanodata, IBM, and lotsa people in between!) based on talking to you about it. >I won't go on in detail here, because I've about covered its relation to >Mike's proposal. Of course I'm working on further versions, and I might >even snitch some ideas from him if I like 'em! Please do. I don't even care if you credit me; like I said, there isn't really anything original, and you can probably find any piece of it somewhere else, if you go looking. Then again, the same is pretty much true of Unix, and look where it got the people who wrote it! :-) Also, if you look at the end, you'll see that the idea was to encourage people to do what you're doing. For another source of ideas, you might look at ZING!, which is a CLI replacement from the other direction. Instead of adding lotsa things to the CLI to make it use the hardware on the machine, you add features to the workbench to make it useable as a mouse-driven CLI. "The easiest way to get software written is to get someone else to write it for you." - Erik Fair <mike
gore@nucsrl.UUCP (01/21/87)
/ mwm@eris.BERKELEY.EDU (Mike Meyer) / 7:45 am Jan 19, 1987 / >...where I first saw some of the basic features: > >Separate input/output: Gosling emacs. >" " in windows: UO LISP >History: InterLISP >click to select, > double-click to run: Apple LISA >Selectable/editable history: ksh >History in a separate window: Me(*) First, let me say that I do like your proposal. I'd suggest, though, that you take a look at XS-2, developed at E.T.H. Zurich. It has most of what you have described. Plus, at very little (if any) extra cost, there are other very helpful features, such as easy user-interface prototyping. The reference I have is: Jan Stelovsky, "XS-2: The User Interface of an Interactive System", Doctor of Technical Sciences Dissertation, E.T.H. (Swiss Federal Institute of Technology), Zurich, 1984. By the way, XS-2 was developed and runs on a Lilith. Last I heard (which was a while ago), somebody at U. of Washington was trying to port it to Unix. Jacob Gore Northwestern University, Computer Science Research Lab {ihnp4,chinet}!nucsrl!gore
pete@topaz.berkeley.edu.UUCP (02/05/87)
[This is a re-posting -- as far as I can tell I sent the first into the ozone somewhere. If you see it twice, my apologies.] In his response to my note that my "Sili(Con:)" command line interpreter already implemented some of his Shell proposals, Mike Meyer gave me a pretty good history lesson on command windows and so on. No disagreement -- I didn't mean to claim that I was the first to think of such a scheme (and he mentioned sources that I wasn't at all aware of). I wanted to point out though that such an interface does already exist for the Amiga. He goes on to say some nice things about Sili(Con:), which I appreciate. Thanks a lot, Mike. Anyhow, I also promised to think about his other proposals and comment, so (a month later) here goes: Mike Meyer writes in "Proposal for an Amiga shell": > >....... >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 User Interface > >When running, ms normally has three windows open, the input window, >the history window, and the output window...... We've been through this already vis-a-vis Sili(Con:)... I have some more thoughts, though. I feel that the command window (I'll come back to why I didn't call it an input window in a moment) and the history should definitely be 'panes' of a single control window as they are in Sili(Con:). Matt's remark about clutter is valid, but I believe -- and use has confirmed -- that there isn't much of a problem as long as you can push the control window out of the way in a hurry when you want, and get it back just as fast. Sili(Con:) has 'hot keys' to do this. If the two windows were separate this would be a lot messier. I used "command" rather than "input" window because I feel strongly that the command "stream" should be kept separate from other interactions. I often first enter a string of commands that I want to execute in sequence, and THEN make responses to any prompts the commands may generate; or, even more critically, I may double-click a sequence from the history window. It's a big advantage to be able to "click-ahead" like that. I don't see any simple recipe for keeping commands and responses distinct if they come in through the same channel. And of course the history would get cluttered up with responses intermixed with commands. I personally would object to that, though I could understand if people wanted the facility to recall responses as well. Now what WOULD be neat would be INDIVIDUAL histories for commands that would pop up each time the command was invoked. My most compelling argument for keeping commands and interaction separate, though, is that I eventually want this whole dinkus to be multi-process. I want only ONE command window, but from it to be able to start up as many processes -- possibly themselves interactive -- as I wish. Any scheme that allowed me to talk to individual programs from the one command window would get pretty baroque. On the other hand, the current version of Sili(Con:) has problems here, too: interaction is through the regular DOS window in which the command output appears, so to interact you have to first click in that window; this can be awkward when, say, you want to stop output in a hurry. The next version will make the DOS window active automatically when you push the control window to the back. In the long term, I suspect the handiest solution is to have all commands that need interaction pop open their own windows for the purpose, like editors and so on do now. >............................................. In addition, at various >times ms can open scrollable output windows, completion windows, and >help windows.... > >............................................................. While >there is no way to recover lines that have scrolled out the top of the >[output] 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. I'm not sure of the usefulness of being able to copy from output to command window, especially if my concerns about separation of function are valid. I can see it being handy to pick out file names and other arguments and splat them into commands you're building, but really there are probably only a few programs you would want to generate this sort of output (DIR for instance) and it would be better to treat these as special cases -- much as DirUtil works at the moment. So rather than allowing pick operations on the normal output window, I suggest another standardized window that could be kept available for picking from. The following may fill the bill...: > >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. I like this concept. There are a few things to think about, though. Like, how does the user create one, and how long should it stay around by default? And how do you discard it? The simplest way to do the last is with a close gadget, but if we are concerned about keeping hands on the keyboard some kind of hot key would be in order. We would want some way of rotating through windows from the keyboard too, like Jim Mackraz demonstrated at the last BADGE meeting. Creation isn't hard; some kind of redirection syntax would be appropriate. Regarding its lifetime, I assume from Mike's description above he is thinking of having it stick around until the next command, but if we are talking multi-process this obviously won't do. I can suggest two options: 1) Leave it around until the user throws it away. This might get onerous. 2) Have a maximum-number-of-windows parameter (2 or 3, say) and discard on an LRU basis. If a user wanted to keep a window around longer he would lock it somehow. (It could still be closeable, but he could bring the data of a locked window back when he wanted it.) As I intimated above, I think it might be a good idea to be able to select items by mouse (and keyboard? -- how?) from scroll windows. The text has to be kept around in recoverable form anyway if you are going to scroll it, while simple output windows only need a bitmap if you otherwise don't want the fancy facilities. > >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. What I think you're suggesting here is a "visible clipboard". Maybe we could call it a smorgasboard... [a little more variety than the usual menu...] :-) This is a valuable idea too. You would be able to pull strings out of any program's output and stash them here for use later. To me it's not so much like the clipboard, where PROGRAMS share data, as like dragging icons around on the WorkBench -- only here you're dragging strings. The programs themselves wouldn't need to know anything about it, as long as their input devices were smart. This brings the line of thought to something I think we've both been kicking around in the back of our minds: something like the Sili(Con:) window should be provided as a HANDLER, for any program to attach to if it wanted. After all, the History is a primitive form of scroll window, really (or will be when I add some scroll gadgets...). > >Completion windows provide an easy way for the user to finish typing >commands or arguments.......... >......................... The system [...] 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,........ >........... >Help windows provide a brief description of the valid inputs in the >current context......... Again, these are great ideas, at least in principle. I have hazy doubts and questions about implementation, but I'll think on't a while. > >User Customization > >[..... Mike presents a LOT of ideas here...] I don't even want to start getting into a discussion of all the suggestions in this section. For now I'll just agree that we need a good command handling protocol; default filespace globbing by the shell is NOT what I want. I think I like the command descriptor file -- but not at floppy speed, please. (We'll soon be keeping EVERYTHING on ramdisk though, won't we?) I apologize for concentrating mostly on windows, but that's what I've been thinking about mostly myself recently. I want to let thoughts on command syntax roll around a while longer. Anyway, Mike, you've started some wheels turning in my mind [well, at least I heard the bearings creak...], so let's keep the dialog going -- and have some input from other people. -- Pete --
mwm@eris.UUCP (02/05/87)
In article <2444@jade.BERKELEY.EDU> pete@topaz.berkeley.edu.UUCP (Pete Goodeve) writes: >We've been through this already vis-a-vis Sili(Con:)... I have some more >thoughts, though. I feel that the command window (I'll come back to why I >didn't call it an input window in a moment) and the history should definitely >be 'panes' of a single control window as they are in Sili(Con:). Matt's >remark about clutter is valid, but I believe -- and use has confirmed -- that >there isn't much of a problem as long as you can push the control window out >of the way in a hurry when you want, and get it back just as fast. Sili(Con:) >has 'hot keys' to do this. If the two windows were separate this would be >a lot messier. I thought about it, and decided I liked having a seperate input & history window, with the history window normally hidden, and a hot-key/menu-click/whatever to get to it. However, the Apollo system also sounds nice; two panes, with all unconsumed input being shown in the "input" pane. >I used "command" rather than "input" window because I feel strongly that >[command input should be separated from commands - paraphrased, mwm.] One of the things that annoys me most about csh history is that it doesn't include input to commands, even some of its own builtins. After using ksh (which did these things right), csh is a pain. Having input to other commands in the same stream is also nice. Of course, if something starts it's own dialog window (more, emacs, vt100, whatever) then it should be left strictly alone. >I'm not sure of the usefulness of being able to copy from output to command >window, especially if my concerns about separation of function are valid. It's nice - when you need it. To hold the expense down, you only keep lines that are visible. Shouldn't be to bad (remember, we're talking about a machine with a meg or more of memory!). >[scrollable output windows] >There are a few things to think about, though. Like, how does the user >create one, and how long should it stay around by default? And how do >you discard it? Left purposely vague. The idea was that the window would be there, "undisplayed" for the last command. You can then ask for it to be displayed, do something to "freeze" it, then later close that window. Unless you freeze it, the next command will cause it to go away. >This brings the line of thought to something I think we've both been kicking >around in the back of our minds: something like the Sili(Con:) window should >be provided as a HANDLER, for any program to attach to if it wanted. After >all, the History is a primitive form of scroll window, really (or will be >when I add some scroll gadgets...). Yes! I've looked into providing a "history" for Unix that works sorta like the script command, so you can get to all of your input back. I know someone who started on this. Of course Xterm and the Suntools console window both have this feature. But you want it for EVERY window that has a line-oriented CON: device. Maybe a "HISTORY:", thats identical to the CON: device, but it lets you pick things up from the display and put them onto a clipboard. With a normal font, even on an interlaced screen, this would take 50x80 or 4K. Not a bad price for that ability... >>User Customization >> >>[..... Mike presents a LOT of ideas here...] As usual, lifted from _lots_ of different places. >I don't even want to start getting into a discussion of all the suggestions >in this section. For now I'll just agree that we need a good command >handling protocol; default filespace globbing by the shell is NOT what I >want. I think I like the command descriptor file -- but not at floppy speed, >please. (We'll soon be keeping EVERYTHING on ramdisk though, won't we?) Well, not on ramdisk. I was thinking about keeping it in an internal tree or hash table (have to look into the problem of command completion - can I do it with a hash table?), with a csh-like "rehash" command. We do seem to have a difference in feel for what a command processor should be. You want it to be a tool for managing multiple processes, etc. I want it to be a tool for dealing with a sequential string of processes. If I need more than one such string, I'll start a new one. Both points have their advantages, and I truly loved MASTER on my old TOPS-10 systems. But I'm not sure that such a thing on top of intuition is such a good idea. Then again, you don't have to worry about split history lists, etc.... >I apologize for concentrating mostly on windows, but that's what I've been >thinking about mostly myself recently. Ah, but that's the interesting part if you've got an Amiga. The second half can be done on a MS-DOS machine, or some large VAX. Not nearly as much fun. If you're interested, that paper has been rescribled to reflect some of the early comments (the user customization part was actually simplified because of some of your suggestions. Thanx, guys!), and shipped off to SIGSMall/SIGPC. Cheers, <mike