Andrew Lentvorski wrote:
>
> On Apr 25, 2005, at 11:19 AM, Michael O'Keefe wrote:
>
> >>C) The whole idea of a whole *class* of metacharacters (space,
> >>slash, backslash, backquote, semicolon, etc.) is an idiotic
> >>*Unix* practice.
> >
> >It's only in interactive shells.
>
> And it's still stupid.
>
> >>The whole idea that quote doesn't shut down the metaness of
> >>*every* character except quote is just a stupid design decision
> >>from the Bourne shell days propagated 20 years into the future.
> >>
> >
> >quote, or double-quote ?
>
> Pick one. Just make it work.
There was a problem with the orinal bourne shell: it has no concept of
array. So, when it exanded $VAR, it broke it into tokens at whitespace.
if your argument needed to have those spaces in the argument (such as rm
$FILE_WITH_SPACES) then you have to protect that word with quotes, so
the shell sees it as one word.
I am sure you are aware of all this.
And, hard quotes totaly do away with $VAR paramer expansions.
This was a terrible problem with the bourne shell, and bash, in its
infinite wisdom, sought to emulate that horrid hackish behavour.
Enter zsh. $VAR will expand as one word. Even if it has spaces.
Wait, let me cannonalise these examples.
So when you use ${VAR} in a command line, you don't need to worry about
putting it in quotes to protect whitespace from being seen as a token
seperator. You can say rm ${FILE_WITH_SPACES} and not worry about it.
You can still use hard quotes to prevent any shell parameter expansion.
So let's say I wanted to loop over a variable, much like sh's ``LIST="1
2 3"; for i in ${LIST}; do proggy ${i}; done. I would use a zsh array
variable: LIST=(1 2 3); for i in ${LIST}; do proggy ${i}; done. What if
I needed a space in a token? We return to the use of quotes: LIST=(1 2 3
"4 four"); for i in ${LIST}; do proggy ${i}; done
Very simple. This is another thing I really like about zsh: It fixes the
problem that has plagued us since the day of sh.
Before the *csh supporters get all high and mighty and claim array
support, yes, csh is broken too:
% setenv a "1 2 3"; foreach i (${a})
? echo ${i}
? end
1
2
3
> The problem is that the interactive shells try to do a weak form of
> programming via string and variable interpolation and thus cause all
> manner of grief in trying to parse strings.
Only sh and those that followed the ``we must break token on
whitespace!'' Zsh does not.
> Your comments about Perl, Python, Java, etc. not needing this are
> straight to the point. The shell should either be A) a real
> programming language with all of the expected features rather than a
> weak pseudo-programming language or B) a file manager that doesn't
> have all of the attendant idiocies.
mc. Solves that problem right there.
> The argument is similar to the one for a build system. A build
> system should be a real programming language with some syntactical/
> library helper functions to make commonly used operations
> convenient. Anything less eventually requires people to tie
> themselves in knots to work around the problems (see Ant, the Java
> build system, for example).
Is Ant an example of a good thing, or a bad thing?
-john
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
