From: johnsd2@jec324.its.rpi.edu (Daniel Norman Johnson)
Subject: Re: More Defense of CLI  (there, I changed the subject ... )
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.
Date: Sun, 4 Oct 1992 19:37:30 GMT

In article <1992Oct3.235607.14542@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:
|> In article <6082.2ac8918b@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
|> >
|> >The only "short-cut" built into DOS (or other CLIs) appears to be the wildcard
|> >matching of the "*". That appears to be the singular advantage of the CLI.
|> >This short-cut is unfortunately limited to a rather constrained task. I have
|> >yet to see any other example presented by CLI aficianados.
|> 
|> There are *lot* of other short-cuts built into CLIs.  I'll use tcsh 
|> under UNIX as an example.

I believe ya. :) But lets see what shortcuts you have the Mac GUI
doesn't have also. (well, if you can look at Unix, I can look at
de Mac, no?)

|> First of all, tcsh has filename completion.  That means, if I type    
|> the first few letters of a filename and hit the TAB key, tcsh will
|> fill in as many of the following letters as it can.  I can then type
|> a few more letter and hit TAB again until I end up with a complete
|> filename.

Of course the Finder and teh standar file dialogs do this.
General I just point-n-click if I remember the name and not the
position, I type it. Poof, its selected. Don't even have to
type all of it. Heck, I dont have to complete it either; it always
keeps the best match so far selected. (thats nitpicking tho)

|> For example, if I have files named "Letter to Bob" and "Letter to 
|> Fred" I can type "Le<tab>B<tab>" to get "Letter to Bob".  If I only
|> had one file that began with "Le" in the current directory, I could
|> just type "Le<tab>". (BTW UNIX filenames can be 128 characters long 
|> and can have embedded spaces, punctuation, etc.

Really? How do you get your shell to deal with Unix filenames that have
embedded spaces in them? [no, Im not saying you can't, Im saying I dont
know how its done]

|>  There's also a UNIX
|> command which can determine the type of a file (C code, PostScript,
|> digitized sound, etc.) by its *content*.  Naturally the command is
|> extensible to handle new file formats as they come along).

A bit of a hack. The system should just _know_, without having
to be asked politely to go figure it out. I wouldn't
call this a feature.
      
|> If I forget what files I have, I can always type a couple letters and
|> then type ctrl-D, which will show me a list of all the files that
|> match.

Naturally, the MacOS also shows you a list of files, although its
just that the list begins with the first file matching the letters
you have typed, and the others just follow it alphabetically. Its
not a special case.

|>  I can also use regular expressions (not just *) to match any
|> set of files that can be matched by a regular expression.

Ill grant you this, but its just a more powerfull wildcard ability.
Not that there's anything wrong with that.

|> Also,
|> there are commands like "find" which let me apply a command to  
|> whatever list of files the command finds.  I can easily tell the find
|> command to apply the print command to all the C files which      
|> are owned by me, readable by others, modified in the last 10 days,    
|> and which don't have any syntax errors, for example.

I'd love to see the command that did THAT! :)

In any case this can also be achieved by drag+drop type apps, that
send apple events to the finder. (but the system doesn't include
the apps to do it- all it has is teh Find command, which tho flexible
cant do all that.)

These apps/commands get the finder to select the found files, and then
you can print, open, or what have you the files.

However, this technique does requires you to prod it along
at each step; it doesn't set up a list of instructions or whatnot
to do and then go do  that while u wordprocessor or something like
that. So you have something here, but perhaps not as much as you
thot.

|> Tcsh also provides command-history editing.  The up and down cursor
|> keys move me up and down my command history, and the left and right  
|> arrow keys allow me to edit a previous command.  When I'm done I just
|> hit return.  I can also apply a substitution to a previous command.   
|> If I accidentally type "fobar" when I meant "foobar", I can just say 
|> "^o^oo" which means that I meant "oo" instead of "o" in the previous
|> command. !n repeats command number n, and !! repeats the last command.
|> There are dozens of other shortcuts which simply don't make sense in a
|> GUI (How would you tell a GUI "oops, I meant to launch SuperPaint, not
|> Canvas" (because they just happened to be next to each other) or "oops, I
|> wanted to shift-click on that 32nd icon, not deselect the other 31
|> icons."  You have to repeat the whole thing from scratch.)

Most of this is indeed inapplicable, so you can count it as a "Feature"
if you like. Id say it was trying to make up from the obnoxious nature
of the CLI.

the last point should be fixable by using the Undo command. (Im
am not sure that it is tho, maybe you have a point)

|> 
|> The fact is, UNIX is so modular that you can do anything you can  
|> imagine.  I've often written scripts which execute a command, take
|> the output of that command and generate more commands from it, and  
|> then execute those commands.  For example, before archie came along,
|> I had a script which would ftp to a site, get a list of ftp sites,  
|> generate a script to ftp to all of those sites, get lists of the    
|> files at those sites, and put the lists into a tab-delimited form   
|> that I could import into a database. And I know relatively little   
|> about UNIX scripting!  The Mac GUI is great for many things, but    
|> there are many areas where a CLI is better.

This is a script. This is something I want. This is something the MAc
should have but doesn't. Grrrrr.

|>  Apple recognizes this, 

Bout time.

|> which is why MPW has a CLI and why they are developing AppleScript.

I dont think MPW is very relevant, its not part of the system.

|> You'll note that, even though THINK C has a better compiler and linker,
|> most serious programs are written in MPW because the CLI offers the
|> power and flexibility necessary for large programming projects.

Assertation. Two of them. (1) Most serious programs are written in MPW;
I have no idea if this is true, it certainly may be. But (2) is
that this is because of the joys of CLIs.

I could just as reasonably say the "Microsoft C is better than Borland
C because most serious programs are writtin in it, for the PC"

But the real reason people use MS-C is because its the standard. The
same applies to MPW. But there's more. All the example progs
are written for MPW; Inside Macintosh references it. (for instance,
it sez that MPW verison somethingorother includes glue to make the
Gestalt trap not crash even if it is not present). MPW gets updated
when teh system does to include new routines, constants, etc. (note that
Think C 4 did not even include the event type constant osEvt (which is used
for multifinder support)

I could probably come up with more, but you see what I mean.

|> If you really think that the GUI is faster than a CLI in every case,
|> try this:  Go into your favorite word processor.  Type a line.  Now 
|> make 5 copies of the line using command-C and command-V.  Now do the
|> same using the copy and paste menu items.  Time each one and tell me
|> which is faster.  A keyboard shortcut is essentially the same as  
|> using a CLI, except you don't need to hit return at the end of the
|> command.

No it ISN'T. Its not even CLOSE. Command lines have parameters. They
have switches. They can have pipes. They have pathnames. They
They can be made in to scripts, effectively. They require you to memorize
commands, whereas keyboard shortcuts do not, because shortcuts aren't
necessary; if you forget the command-equivalent, you can use the menu.

|>  CLIs may have a big disadvantage in terms of the time it 
|> takes to learn the commands, but they often have a big advantage in
|> speed, especially when you were already on the keyboard anyway and
|> don't need to make an extra trip to the mouse and back.  If you agree
|> that the CLI is faster in this case, you have to agree that there are
|> essentially infinitely-many cases where the CLI is faster.

I don't. You could make a case that keyboard shortcuts are faster,
at least if you memorize them well enough, but trying to remember a comand,
its parameters and switches, spelling it right, correcting typos, and
typing it (etc etc etc you get the idea) does not seem particularly
fast to me, not compared with graphical alternatives.
(point to a button, click. Point to an icon, double click. Or pull down a
menu, release)

It might come close if teh command was short, frequently used and you
had a good handle on the parameters. [example: Id expect rm * to be
comparable with select-all, drag to trash. It might even be better,
if you had memorized rm well enough]

-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
Newsgroups: comp.sys.mac.advocacy