There follows a fairly random collection of witterings on the subject of the Unix shell and various other command interpreters, mostly from the University of Cambridge local newsgroup ucam.chat. This may coalesce into something more useful at some point.
>I suspect that in a shell language there's no such relation and >any given switch might have totally opposed effects as a modifier on any >given command.
With the current Way of Things on Unix, it's not the shell but the individual programs that define what switches and command line parameters are available, and as you say you can get switches meaning completely different or even opposite things (-v: Verbose or inVerse?). I suppose this isn't surprising if you only use single letters, since there are only 26 of them available!
Whether or not you want your switches to be consistent everywhere, I think it really ought to be the shell that knows what switches and arguments commands (which now become distinct entities from programs). Your shell has some sort of database of all the commands that are available on the system, their switches, arguments, and perhaps a short help text for each switch. Now you can tab complete across command options, or your speech recognition system can have an idea of what you might say next; if you've forgotten what the -i flag to spingle does, you can hit your `HELP' key and you'll get a short reminder and be left back at your command line, or perhaps you have a little help window continually providing feedback on the current command's options. You missed something out of the command line? Maybe you'd like to be prompted for what you left out when you press enter?
People who've used VMS will recognise DCL in some of what I'm talking about, and doubtless people who used Phoenix (RIP) can tell about how the command line interpreter there was friendly. I think something which tries to be a `revenge of the command line' for Unix would be at least an interesting experiment...
>>> [I'm in favour of GUIs because they] move the conceptual model >>> away from a command-response dialogue in which the instruction is >>> the basic unit of interaction to one in which the thing being >>> acted on is paramount. >> >> This last is nothing to do with graphics (regardless of whether you >> think it is a good or a bad thing). > >True, it's not inherent in a GUI, but I can't think of a good way to do >it in a text-system. I'd be interested to hear other people's ideas...
We're on a command line here which has a special character ('?') which when typed causes the computer to show you what you might want to do next and then leave you where you were on your command line:
$ carrotplanting.doc? edit view print cut clip move use $ carrotplanting.doc print [Printing carrotplanting.doc]
Maybe we have some easy way of referring to files rather than typing their names, or perhaps the command line has some idea of `current file':
$ carrotplanting.doc use [Current file is now carrotplanting.doc] $ view [...blah...] $ print [Printing carrotplanting.doc] $ ? carrotplanting.doc potatodigging.doc edit view print cut clip move use $ potatodigging.doc use [Current file is now potatodigging.doc] $ print
I've not developed this example, but it shows that there's nothing inherently graphical in this sort of object-orientation. Anyone who actually wrote such a thing would doubtless find many more ways of making it easier to use.