Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!qantel!hplabs!ucbvax!jade!dunsel!mwm From: mwm@dunsel.berkeley.edu (Mike Meyer) Newsgroups: net.unix Subject: Re: Mac<->Unix interface Message-ID: <1317@jade.BERKELEY.EDU> Date: Sat, 20-Sep-86 20:07:42 EDT Article-I.D.: jade.1317 Posted: Sat Sep 20 20:07:42 1986 Date-Received: Sun, 21-Sep-86 22:03:49 EDT References: <5872@topaz.RUTGERS.EDU> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@dunsel.UUCP (Mike Meyer) Organization: Missionaria Phonibalonica Lines: 64 Keywords: foo bar In article <5872@topaz.RUTGERS.EDU> dpz@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!