Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!brolga!lingua.cltr.uq.OZ.AU!root
From: root@lingua.cltr.uq.OZ.AU (Hulk Hogan)
Newsgroups: comp.arch
Subject: Re: UNIX mind-set (was: How wrong is MS-DOS?)
Message-ID: <1991Jan16.033056.12332@lingua.cltr.uq.OZ.AU>
Date: 16 Jan 91 03:30:56 GMT
References: <8148@hub.ucsb.edu> <11313@lanl.gov> <1991Jan14.055453.21780@lingua.cltr.uq.OZ.AU> <2459@opal.cs.tu-berlin.de>
Organization: Centre for Language Teaching and Research, Uni of Queensland, AUSTRALIA.
Lines: 63

wg@opal.cs.tu-berlin.de (Wolfgang Grieskamp) writes:
>root@lingua.cltr.uq.OZ.AU (Hulk Hogan) writes:
>>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.

>>One last time.  After you hit the RETURN key to terminate your input,
>>the shell parses it. Leaving aside how it handles redirections and pipes,
>>it globs the wildcards (which haven't been quoted) and then executes the
>>specified programs with the globbed arguments.

>Wrong. It first checks the variable "noglob" and does only substitutions
>if this is unset. So, in a way, the statement is correct, that the
>shell performs no automatical wildcard substitutions... :-)

Wrong. (My turn for nitpicking!) In csh/tcsh, there is a noglob variable.
In sh, you have to "set -f".  Perhaps I should have mentioned that in my
article, but I thought it would only complicate things, as simple points
were having tremendous trouble being understood.  Jim Giles said that the
tool had to ask the shell to glob wildcards. This was patently false.

>Beside this needle-picking, i would agree to Jim Giles original arguments 
>in the following sense: The UNIX shell command language (in which you 
>might view commands like "grep" and "ls" as standard procedures) is to 
>weak to handle real information processing problems. OK, you can do
>nearly anything, but how? Its a mess to work with this ugly 
>non-straightforward kinds of quotations etc. pp. seriously. 

But what is the solution?  I love C, and I agree (see later articles by me
and others) that many of the great things you can do on the Unix command
line can't be done in easily in C because the libraries don't support them
(and popen(3)'ing subshells for globbing etc is a real pisser).

>On the other hand, DOS has no command "language" at all ... but a lot
>of comfortable "harded-wired" information managers, f.i. norton
>commander. You cannot freely configure this tools for your needs. 
>So you go and buy the next one ...

Thank God Unix doesn't do the DOS "solution" of giving you a braindead
.BAT language and bundling BASIC.  (Maybe this was Microsoft's version
of giving the user shell and a bundled C compiler... :)

Whilst shell script is missing lots of programming stuff you get in C
(although the newly introduced functions are a huge gain), it is much
easier for most people to use and very fast at hacking up new commands.

For the non-computer-professional, being given shell is a pretty good
compromise IMHO.  For the professional, it saves endless vi/cc-ing every
time you want to create a new tool.

/\ndy
-- 
Andrew M. Jones,  Systems Programmer, 	Internet: andy@lingua.cltr.uq.oz.au
Centre for Lang. Teaching & Research, 	Phone (Australia):  (07) 365 6915
University of Queensland,  St. Lucia, 	Phone (World):    +61  7 365 6915
Brisbane,  Qld. AUSTRALIA  4072 	Fax: 		  +61  7 365 7077

"No matter what hits the fan, it's never distributed evenly....."