From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Subject: Re: The Problem with UNIX
Date: Wed, 11 Nov 1992 12:24:08 GMT
Organization: The Programmer's Pit Stop, Ann Arbor MI

In article <17310@mindlink.bc.ca> Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg) writes:
>and programs, the touchiness of such things as "mv * x" versus "mv *x"
>ought to give most people pause. And how many of you experienced Unix users,
>as SOME point, have aliased rm to "/bin/rm -i" --- probably just after
>deleting a week's worth of source code?

Hmm.  This example of "one misplaced space can destroy your command"
keeps coming up over and over again, but I've never actually seen it
happen.  Sure, if you put a space where it doesn't belong, Something
Bad might happen.  Then again, if you type "rm $MAIL" instead of "frm
$MAIL" (this one is even easier to do, since all you have to do is
leave out a single character), you'll blow away your mailbox instead
of getting a summarized listing of it.  So what?  If you click on
"Delete" instead of "Open" you'll blow away your file, too.

I've never aliased "rm" to "rm -i", and despise people who do.  The
few times I've accidentally blown away a file, it was never by
accidentally rm'ing it; no, it was much more creative than that.  (One
specific example: Once, as root, I typed "crontab news" instead of
"crontab -l news" while in /var/spool/cron/crontabs.  Of course, the
crontab command took this to mean "replace the current user's crontab
file with the contents of the `news' file", and so I overwrote root's
crontab with news's.  This is probably a better example for "know what
you're doing when you're root" than for "the Unix CLI is obtuse".)

>a la VAX/VMS or CMS. And an environment that allows classes and
>subclasses can provide the same interactive flex as the shell
>(well, the Korn shell or better) while adding a layer of "do what I
>want, since it's obvious" to such cases as "mail xyz <a.out".

Uh, right.  Please see the definition of {DWIM} in the Jargon file.

>(sockets bound to names, streams, devices). But even more common
>is the "typed" nature of text files. We kludge around with file suffixes
>as identification to other humans; and we kludge around even more
>with magic numbers, /etc/magic and "file" to make guesses as to
>what a file is good for. How about the "ls" command that checks
>whether stdout is a device or a file, and behave differently
>in either case? Give me a break!

Typed files also have problems.  I'm no Mac expert, but I fondly
remember the problems I had trying to convince the Finder to run a
file that I had just downloaded.  I still don't remember exactly how I
fixed it, but I know it wasn't as easy or obvious as "chmod +x file".
And do you really want to be told, "Sorry, you can't edit an
executable" by your editor?  If I typed "emacs /bin/ls", I probably
meant it...

-- 
Marc Unangst, N8VRH         | "There are two ways to solve this problem:
mju@mudos.ann-arbor.mi.us   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture
Xref: sparky comp.unix.misc:4050 comp.protocols.tcp-ip:5057 comp.lang.postscript:5381