From: johnsd2@vccsouth07.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: Mon, 5 Oct 1992 16:31:06 GMT

In article <1992Oct4.232553.16720@nwnexus.WA.COM>, kanefsky@halcyon.com (Steve Kanefsky) writes:
|> 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.
|> 
[deletia- filename completion]
|> >
|> >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. 

This is true, but then point and click takes care of it in the
vast majority of cases. If you happen to be looking for antidiestablishmen-
tarianism512, well then I guess filename completion has its points. :)

But this never happens to me, anyway. Does it happen to you?

[deletia- how to get imbeded spaces in Unix filenames. Now I know]
|> 
|> >|>  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. 
|> 

I disagree with your disagreement. The macs type code is NOT a filename
extensions- you CANNOT change it by renaming the file (or any other
finder operation);

The problem where the type ain't right doesn't seem to happen to me
(now I feel left out...) Care to provide some examples of that?

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

Ok. I was actually thinking standard file dialogs, and missed that
detail. :(

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

IF you remember the syntax it's usefull.

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

So I did.

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

Well, nifty! :) Your find command its lots more flexible than the
Macintosh find command is. Yout point.

However, aren't you COMPILING the program to see if it syntax checks?
Isnt that a bit slow? Wont it generate errors sometimes if the file
depends on other files, that may not be present, even tho it is
syntactically ok? What if it fails to link (etc...)

Isn't there a command to check the syntax alone? lint or something
like 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.)
|> 
|> 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. 

No, I am NOT saying that. Apple Events are not user-level things. The
finder program sends an apple event ot the finder. All the user
sees is that some windows in the finder open with some files
selected. No 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. 

I dont know about Commando. This isn't a CLI (the Mac hasnt got one!)
and prodding it along is only important if the operation takes a long
time.

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

A "good" GUI would maket he commands so simple that the command history
is just as much work as the operation. (ie, move a file is just
dragging it...) but this isn't always the case. :(

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

Ahem. I would say scripts are usefull in their own right, wo/ a CLI.
See your own example for how this may be.

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

How is THAT in common with other Mac users. (lots of users?l lots of
files? You lost me..)

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

I guess they like CLIs, or else MPW provies a lot of very nice tools,
that run on the CLI. (but perhaps they'd be even better
graphical? I dunno, I dont know what the tools are we're talking
about...)

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

I dont know about Commando, so I cant relly comment on it.

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

Modifier keys are more like commands with slightly different names,
than switches (usually); They also provide fewer possibilities. (there
are only 4 or so modifiers, but lotsa possible switches)

As to teh juxtiposition, it doens't do the same thing. With pipes
you can set it up and let it run, with keyboard equivalents you can't
do so. (you could rely on your keyboard buffer, but then what if something
goes wrong with one of the commands? What about parameters, etc..)

Also, the point that theys equivalents are faster is disputable.
(and has been disputed, and nobody ever convinces anyone of anything
about it, so lets not bother...)

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

The GUI can (and should) make more common operations much simpler
than this. Example: Finding a file by a partial name in the MAcOS
is just command-f (or the find command), type in the partial name,
press return.

Its true the obscure options MAY require going through various subdialogs,
in an average GUI, but then in the CLI you'd have to remember the
command somehow. Or can you remember ALL the options for your
commands? :)

Also, in a well done GUI arrangement, the dialogs you mention should
be unnecessary. (but this can be very hard to arrange, and its
pretty rare); I cant get much more specific than that until you give me
an example of an operation that has this nested-dialog problem.

Incidentally, what about Remembering the command line commands?
I mean, rm and mv are no problem but what about the obscure,
infrequenty used ones...

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

The CLI is better for a few operations, if you've memorized the commands,
options, wildcard syntaxes, etc, and if you remember them all (so
you dont have to look anything up)

I wouldn't say the CLI is better for things like move that file to
that directory sort of arrangements, in general.

For instance, to delete a file you have to find it (by name) in a CLI,
and that means lsing or ls | more ing or whatnot, then spelling it right
(for which command completion can help, sometimes). Better to just
grab it and throw it away, imho. Of course, it may not be so clear
in all cases its the right file- in the GUI you have the aditional
cues of its icon and position in the window to help you with that,
and if you need it you can also throw in a comment. And if that's
not enough you can look at it w/ just a double-click; you dont have
to know what program to use to open it.

Im just saying that once you memorize the CLI it can be comparable for
some things with a GUI, not that once you have done so the CLI is always
better. I dont agree, I think its a cumbersome pain most of the time.

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