NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/wizards/4814

Text File | 1992-11-20 | 3.7 KB | 80 lines

Newsgroups: comp.unix.wizards
Path: sparky!uunet!munnari.oz.au!yoyo.aarnet.edu.au!news.adelaide.edu.au!augean.eleceng.adelaide.edu.AU!hfrd.dsto.oz.au!dall
From: [e-mail] (Ian Dall)
Subject: Re: The Problem with UNIX
Message-ID: <[e-mail]>
Sender: [e-mail] (Ian Dall)
Organization: Defence Science and Technology Organisation
References: <[e-mail]>  <[e-mail]>
Date: Fri, 20 Nov 1992 02:57:43 GMT
Lines: 68


In article <[e-mail]>, [e-mail] (Daniel Smith) writes:
> In <[e-mail]> [e-mail] (Michael Lemke) writes:
>
> > In article <[e-mail]> [e-mail] (Ben Ketteridge) writes:
> > >For example, just to take the 'cat a b > b' problem, you are suggesting IMHO
> No it isn't, consider my "glasses of water" theorem:
>
>
>          |         |          |           |
>          |~~~~~~~~~|          |~~~~~~~~~~~|
>          |         |          |           |
>          |         |          |           |
>          |    A    |          |    B      |
>          |         |          |           |
>           \_______/            \_________/
>
>
> Ok, B can get bigger (i.e. a goblet, or a pitcher) to accept water
> from A, but what do you mean to do with B's original water?

The solution of the problem to to mv cat pour :-)

It is true that (if you don't know unix) you might think cat a b > b
means concatenate a with b and stick the result in b. This actual
behaviour is somewhat counter intuitive although this sort of problem
is not unique to unix. I'd be generally suspicious of using three
operand 'commands' (statements, functions, procedures whatever)
with the output operand the same as one of the input operands unless
I *know* it works. Eq we expect a = a * b to work. But suppose a and
be are matrices, we wouldn't expect mat_mul(a, b, a) to work unless
we were told it was safe.

The question is not just whether "cat a b > b" should do something
sensible, but whether it should warn the user. The latter is possible,
by means of stat and many (most?) cats produce a warning even though
it is the shell which has done the redirection.

Things like "cat a b | cat > a" are a lot more tricky to detect and
frankly I don't see that you can do much except give users who can't
understand pipes and redirections an interface which doesn't use
those concepts. Power is risky.

The question of whether to glob in the shell or in the process is a
little different. Here we are talking about a design decision on where
to draw the lines when splitting up the desired functionality.
Ideally, modules shouldn't have to know much about other modules. So
*if* a major design goal is VMS like renaming, then globbing in the
shell is a bad decision. On the other hand, it is not impossible --
you could for example have a table of "installed" processes and their
arguments which the shell could refer to. The simplest thing would
be to just not do the globbing for those processes leaving it to the
process but you could have some sort of syntax to describe what should
be done with the arguments.

I'm not suggesting I want such an interface (I like knowing exactly
what the *s etc are going to do), just pointing out that a) it is
possible but that b) requiring the shell to know about processes is
not clean because it breaks the original "modularization". So, coming
to the original project, I can't see it being of much interest to
people who *want* unix features. For less sophisticated users, maybe
a shell in general (and the csh in particular) are not the solution.

--
Ian Dall          I'm not into isms, but hedonism is the most
                  harmless I can think of. -- Phillip Adams

internet: [e-mail]