From: kanefsky@halcyon.com (Steve Kanefsky)
Subject: Re: More Defense of CLI  (there, I changed the subject ... )
Organization: The 23:00 News and Mail Service
Date: Sun, 4 Oct 1992 23:25:53 GMT

In article <9aqzm-g@rpi.edu> johnsd2@rpi.edu writes:
>In article <1992Oct3.235607.14542@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:

>|> 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?)

Absolutely.


>|> 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)

Well, the finder has a certain subset of this functionality.  You
can type the first few letters, but if there are lots of files
beginning with the same first few letters, you're stuck after that. 
Say that I have the files "antidisestablishmentarianism1",
"antidisestablishmentarianism2", "antidisestablishmentarianism3",
etc.  I just type something like "anti<tab>3" If I want the one that
ends with "3".  With the standard file box, you have trouble even
distinguishing long filenames that are nearly identical, and if you
have enough of them you have to scroll around to find the one you
want even after you type the first few letters. 


>|> 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 are a couple ways.  You can precede the space by a backslash,
or you can enclose the whole filename in quotes.  Tcsh is smart
enough to fill in the backslashes for you if you hit tab to complete
a filename with embedded spaces. 


>|>  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.

I disagree.  I think it's more of a hack to use filename extensions
than to judge the actual content of the file.  The file type that
the Mac uses is really just a different flavor of filename
extension.  You often have to hack the file type to get a program to
recognize that it can open the file, even though the content of the
file is of the correct type. 


>|> 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.

If you're in the Finder you'd have to switch views to see this, if
you have any other view than "By Name." I agree that this isn't a
major distinction, however. 


>|>  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.

Well, it's very useful so I wouldn't say "just."


>|> 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! :)

Well, you asked for it...


find . -type f     -exec is_c {} \;    -user kanefsky    -perm 644 \
  -ctime 10 \    -exec cc {} \;    -exec lpr {} \;


"find" is the name of the command

"." says to look in the current directory

"-type f" says only to look at files (and not directories, etc.)

"-exec is_c {}" calls a little one-line script which checks the
content to see if it's a c program.  I could have just checked files
that ended in ".c", but since I mentioned content-based file type
above, I thought this was more appropriate.  The "is_c" script just
contains the line
  "file $1 | grep "c program text"
I could have embedded that in the find command itself, but it was a little
cleaner this way and I might want to reuse that command later.

"-user kanefsky" checks that it's owned by me

"-perm 644" checks for read permission by others.  Actually I would have
to check some other permissions other than this specific one, but you get
the idea.

"-ctime 10" checks that it was changed in the last 10 days

"-exec cc {} ;\" checks that it compiles ok (i.e. no syntax errors)

"-exec lpr {} \" prints the files that made it this far



>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.)

And would those apple events be command lines, or graphical?  What
you're saying is that you can *execute* the command using a GUI, but
you have to *specify* it using a CLI. 


>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.

Not having to prod it along means a lot.  Besides, you implied above
that you still need a CLI (apple events) to specify what needs to be
done. Actually, there are graphical interfaces to CLI commands
(Commando in A/UX and MPW, for example.  They're great ways to learn
how to use the options of a command, but they are *much* slower than
the CLI once you learn how the command works. 


>|> 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.

Even if you don't make any mistakes, command history editing is very
useful for repeating a command you just did a few minutes ago, or
executing a series of commands with just a small change in each
command. 


>|> 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.

Well the graphical version of a script is a macro recorder like
Tempo II or Quickeys.  Clearly it's also desirable to have CLI
scripts because it's also desirable to have a CLI. 


>|>  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.

Well, programmers are a class of Mac users who have a lot in common
with other Mac users (i.e. Managing lots of people working on lots
of files).  The CLI tools that MPW provides make this a lot easier. 


>|> 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"


Well, you're right that what I said doesn't follow from the premise. 
However, I've heard lots of testimonials from experienced Mac
programmers who think MPW is better because of the CLI tools,
despite the inferiority of the compiler. 


>|> 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.


I wholeheartedly agree that CLI's are terrible in terms of the
learning curve.  I'm in favor of providing both a GUI and a CLI,
since they each have their advantages.  I like Apple's Commando,
which I mentioned earlier, because it gives you a friendly graphical
way to learn the CLI.  Once you learn it, you can save lots of time
by using the CLI directly.  If you forget, you can always go back to
Commando. 

Nevertheless, keyboard shortcuts really are like CLI's.  They are
somewhat simpler, but you can think of modifier keys as different
switches and options that you have to remember, and you can think of
the juxtiposition (sp?) of keyboard shortcuts as pipes.  In either
case it's a faster way to perform something at the expense of having
to memorize something. 


>|>  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)


Commands that correspond to a single point and click are usually
very simple (e.g. "ls", "cd", "rm", "mv").  The complex commands
like the find command above would take dozens of clicks and
keystrokes to accomplish, and you'd have to navigate through several
dialog boxes because there are far too many options to fit into a
single dialog box.  Assuming you've memorized the options (and I
agree that CLIs are inferior until you have learned them), it's far
faster to correct any typos using a good command editor than it is
to navigate through all the dialog boxes and push all the right
buttons. 


>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]

That's exactly my point.  The CLI is only better when you've
memorized the commands.  The best system is a combination GUI/CLI. 
The GUI is excellent for some types of commands and can help teach
the CLI.  You can even combine the two to some extent by adding
graphical features to the CLI (e.g. graphical editing of the command
line itself, menus to bring up help or Commando, etc.)


--
Steve Kanefsky