From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Subject: Re: The Problem with UNIX
Followup-To: comp.unix.wizards,comp.unix.shell
Organization: McGill Research Centre for Intelligent Machines
Date: Fri, 13 Nov 92 09:19:14 GMT

[ I am removing comp.unix.misc from followups.  It's posted to two
  other comp.unix.* groups; comp.unix.misc is inappropriate. ]

In article <1992Nov11.194557.16258@yarc.uucp>, scott@yarc.uucp (Scott Beckstead) writes:
> In article <aldavi01.721333614@starbase.spd.louisville.edu> Arlie Davis <aldavi01@starbase.spd.louisville.edu> writes:
[stuff we've all seen plenty of times already]

> I agree an experienced user should be able to recognize and avoid the
> problems above.  What's wrong with the shell catching such obvious
> errors and either reporting them or taking other appropriate action
> (ie correcting them).

(Is that an unfinished sentence, or a question with no question mark?
Given context, I'll assume the latter.)  What's wrong with it?  First
of all, it's impossible.  Specifically,

	cat a b > b

How is the shell supposed to know that cat is going to interpret its
arguments as filenames, and what's more, output the contents of those
files?  Consider instead "echo a b > b".[%]

	rm -filename

How is the shell supposed to know whether the user intended that
argument as a filename to remove or an option to rm?  In at least some
cases (eg, -i) only the user knows.

	mail someone < a.out

How is the shell supposed to know that mail takes only printable text?
It can't.  Perhaps this version of mail is a new whizbang mailer in
test that does take binary files....

In all of these cases, the shell has to know quite a lot about the
semantics of the program being run.  It cannot know all about every
program, and I submit that partially protecting users from themselves
is worse than not doing it at all.

Besides all that, these aren't always mistakes.  I once wanted to fill
up a filesystem in a hurry, so I copied /vmunix to foo and then did
"cat foo >> foo".  I was *extremely* annoyed when cat said something
along the lines of "input foo is output" and refused to run.  I had to
waste a pipe and do "cat foo | cat >> foo", and then realized that the
extra copies involved in the pipe were slowing down the operation and
switched to using dd, which mercifully had not been broken by some
overzealous fool trying to keep people from shooting themselves in the
foot.

> I realize that this will get me screamed at by all you guru types
> that advocate that all shell users be rocket scientists or why bother
> using a computer anyway.

I don't see what rockets have to do with it.  *deadpan look*

No, you misunderstand.  Not "why bother using a computer anyway" but
"why use a system which wasn't designed for you and isn't suited to
you".  UNIX was built by hackers for hackers, and hackers seem to like
it just fine.  If you don't like it, by all means, don't use it.

> However I see no reason NOT to research the subject.  If UNIX could
> be made more user friendly by modifying the shell it might gain more
> acceptance in the general microcomputer market place, GUIs not
> withstanding.

Yes, it might.  So what?  Is "acceptance in the general microcomputer
market place" something we wish for UNIX?  If it means dumbing down the
interface until people no longer have enough rope to hang themselves,
well, you can if you want, but I'll keep using what I've got.

[%] Yes, I know there are shells with echo built in.  The point I'm
    trying to make is still valid.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc