Path: utzoo!attcan!uunet!spool2.mu.edu!uwm.edu!linac!att!pacbell.com!ucsd!hub.ucsb.edu!tom
From: tom@bears.ucsb.edu (Tom Weinstein)
Newsgroups: comp.arch
Subject: Re: UNIX mind-set  (was: How wrong is MS-DOS?)
Message-ID: <8166@hub.ucsb.edu>
Date: 14 Jan 91 10:17:14 GMT
References: <8148@hub.ucsb.edu> <11313@lanl.gov>
Sender: news@hub.ucsb.edu
Reply-To: tom@bears.ucsb.edu
Organization: Silicon Graphics Inc.
Lines: 49
In-reply-to: jlg@lanl.gov's message of 14 Jan 91 01:23:14 GMT

In article <11313@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <8148@hub.ucsb.edu>, by tom@bears.ucsb.edu (Tom Weinstein):

>> And you've been using UNIX for ten years?  The shell does wildcard
>> substitution, not ls.  You could just as easily type 'echo x*y'.

> Yes, you could type 'echo x*y' - which would write the string 'x*y'
> on your terminal.  The shell does no wildcard substitution on any
> argument _automatically_.  The tool has to ask for the functionality.

Argh!  Was I unclear?  You are completely, 100%, totally wrong.  ls does
absolutely no wildcarding.  ls does not ask the shell to do so.  There
is a shell variable called noglob that tells the _shell_ whether or not
to do it.  No process external to the shell can set this variable.

> Doesn't effect the validity of my previous point any.  The use of
> 'ls x*y' is redundant with 'ls | grep x*y' in contradiction to the
> "one tool = one simple function" paradigm.

Wrong.  'ls x*y', in the absence of shell wildcarding, would look for a
file named x*y and list it, or its contents if it is a directory.
'ls | grep x*y' would do something completely different from 'ls x*y' in
the presence of shell wildcarding.  In particular, it would list each
file on a seperate line.

> In fact, the paradigm itself is a fraud.  Nearly all UNIX tools have
> options and arguments which cause them to do several distinct things.

This may be true in some cases.  I'm not at all sure that it is true in
most.  And even if it is, all you seem to be saying is that you would
have split the functions up into tools in a different manner than the
implementors of UNIX did.  Your way may be better, or it may not be, but
I hardly think it constitutes a good argument against UNIX.

> The difference between that state of affairs and the one I would
> recommend is that the UNIX tools each implement a rag-tag assortment
> of capabilities.  What I recommend is that each tool implement a
> complete set of closely related functions in a well thought out way.

Hmm, weren't you arguing against a tools approach a little while ago?
Or do you mean applications instead of tools?  I make the distinction
because I'd view things like grep or awk as tools, and things like emacs
or Microsoft Word as applications.  If you really do mean tools, I'm a
bit surprised as I thought you were just arguing against such an
approach.

--
He is Bob...eager for fun.         | Tom Weinstein  tom@bears.ucsb.edu
He wears a smile... Everybody run! |                tweinst@polyslo.calpoly.edu