Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!wuarchive!udel!princeton!phoenix.Princeton.EDU!pfalstad
From: pfalstad@phoenix.Princeton.EDU (Paul John Falstad)
Newsgroups: comp.arch
Subject: Re: UNIX mind-set  (was: How wrong is MS-DOS?)
Message-ID: <5339@idunno.Princeton.EDU>
Date: 14 Jan 91 13:24:16 GMT
References: <8148@hub.ucsb.edu> <11313@lanl.gov> <8166@hub.ucsb.edu>
Sender: news@idunno.Princeton.EDU
Organization: Princeton University, Princeton, New Jersey
Lines: 38

In article <8166@hub.ucsb.edu> tom@bears.ucsb.edu writes:
>In article <11313@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
>> 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

Perhaps he uses sh, and tried "echo x*y" from the command line just
before he posted.  It worked, probably because he doesn't have any x..y
files in his directory.

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

Even if you turned on globbing for the "ls x*y" and turned it off for
"ls | grep x*y", this would still be wrong, since the regular expression
"x*y" does not do the same as the shell pattern "x*y".  The latter
matches filenames starting in x and ending in y, while the former matches
filenames containing a string consisting of an arbitrary number of x's
followed by a y.

Ignoring this, however, you might perhaps have a point (on ls x*y being
redundant) if the shell did globbing only for ls.  It does globbing for all
commands, however.  What about rm x*y?  I suppose you could get the same
effect by using rm `ls | grep '^x.*y$'`, but it takes longer to type and
is less efficient.

I'm not sure if the shell is really a 'tool', however.  I don't think
ksh, bash, and tcsh follow the "one tool = one simple function"
paradigm.  The shell is more of an application IMHO.

--
"Uh, Air Zalagaza 612, we have engine failure and our port wing is about
to drop off.  We anticipate a crash situation at this time."
The lavatory is engaged.  From within, you hear what could be a pygmy hog
giving birth to an unusually large litter.