Mac<->Unix interface

[Mike Meyer]

In article <5872 at topaz.RUTGERS.EDU> dpz at topaz.RUTGERS.EDU (David P. Zimmerman) writes:
>The present Macintosh interface could do nicely for a Unix front-end
>with some work.  Put the Mac screen in a full screen, resizable
>window.  At the bottom of the window, add a command line.  Just above
>the command line, have a single line of graphic gadgets symbolic of
>redirection, appending, piping, etc, and "go".  Add gadgets to the
>window border to shove it to the back, to "cd ..", and to start a new
>shell.  This is your basic shell.
>
[Rest deleted - follow the references if you haven't seen it.]

I like it. It seems to neatly bundle up the nice features of the Unix
shell in a Mac-like interface. One problem is that there are 400+
commands on most Unix systems. Making all of those accessable as
gadgets won't quite work. But see below on dealing with $PATH. Let me
attempt to deal with some of the outstanding problems.

>I am tempted to deal with command-line options like GEM does - specify
>in the application icon/description whether it needs options.  If it
>does, ask for them.  Of course, in specifying the options you could
>use redirection and such with the appropriate gadgets.

Not sure how GEM asks for them. If you're going to have an icon
description, why not make it a template showing English descriptions
of the options, and how to get them. The shell then maps between
"Option Description Language" and gadget imagery. For example, a
simple sort description would have three gadgets, one which toggled
between forward and backward sorting, and one which toggled between
numerical and alphabetical. The last gadget would be to go. Of course,
just typing options at the command line should ALWAYS work, so the ODL
interface could be added later.

>Comments?  A problem I see right away is that, say, piping a program
>in /bin to a program in /usr/local/bin, without using the keyboard,
>involves a lot of directory hopping with the mouse.  Possibly a
>different way of Viewing the programs would help.

Why? Just make each directory in $PATH a menu, and the applications in
it menu entries. They can then be used just like the applications in
the shell window, except you have to pick them up off the menu. This
lets the experienced user get to all the Unix commands they want.

>One thing we must keep in mind is that shell use and shell programming
>are two different beasts.  I have described shell use.

I disagree. I tend to use shell history + aliases as a "small"
programming language. A user doesn't have to be very sophisticated to
do that. You can actually provide most of this by adding a history
mechanism to your shell. Let's take the one I'm putting into
MicroEmacs and see how it works in this environment.

We're going to add another window to your shell, called "History."
Every time the go button is hit, or something is double-clicked, the
shell appends the command line it's goint to execute to the History
window. When you are in the History window, it is a stock editor
window, with one extra facility. You can paste text (& graphics, etc)
back to the shell. This causes the shell to run the pasted commands as
if they had been entered by the user. This history interface would
probably be nicer than any I've dealt with before - a real editor +
the ability to rerun blocks of commands.

Hmmm - I think I like this interface. Now, to get someone to write it!

	<mike