Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!sgi!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.unix.questions
Subject: Re: * Question
Message-ID: <779@quintus.UUCP>
Date: 30 Nov 88 11:17:51 GMT
References: <17661@adm.BRL.MIL>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 94

In article <17661@adm.BRL.MIL> wmartin@almsa-1.arpa (Will Martin -- AMXAL-RI) writes:
>Under "csh", if "bar" doesn't exist, I get: "/data/sa*/bar: No match",
>but, if "bar" DOES exist, and I do either:
>
>cat foo > /data/sa*/bar   or    cat foo >> /data/sa*/bar
>
>it will work OK! So "csh" expands the wildcard * correctly in this case.
>
>And, if "csh" lets this work
>as shown, why does it NOT work when creating the file initially?

When you give a wildcard pattern in Csh, there has to be at least one
thing in the file system which matches the complete pattern.  Suppose
you have an empty directory /data/savewhatsit/ and no other directories
matching /data/sa* .  Where then is there anything that matches the
**whole** pattern /data/sa*/bar ?

If you just want to save yourself a lot of typing, use a shell variable:

Csh:	set sa=/data/sa*
	echo works first time >$sa/bar

Sh:	sa=`echo /data/sa*`
	echo works first time >$sa/bar

Your message was /usr/spool/news/comp/unix/questions/7149 here.
In the Bourne shell, I did
	
	$ NEWS=/usr/spool/news
	$ cd $NEWS/comp/unix
	$ echo que*/7149
	$ echo $NEWS/co*/un*/que*/7149

and both echos worked.  This was on a Sequent, and the test worked in both
the "att" and the "ucb" universes.  For some real fun, I went to my home
directory and made a subdirectory zabbo containing a file fred.

	$ echo trouble >zab*/fred
	zab*/fred: cannot create
	$ x=zab*/fred
	$ echo $x
	zabbo/fred
	$ echo real trouble >$x
	zab*/fred: cannot create

Let's get this last one out of the way first.
	$ echo "$x"
	zab*/fred
We see from this that when a variable is assigned a value, that value
is not wild-card expanded ("globbed").  But if you use the value of the
variable later in a context where globbing is done, the value will be
globbed then.  That's why I wrote sa=`echo /data/sa*` above.

What about ">zab*/fred"?  Why didn't that work?  Well, you have to read
the Sh manual page with extreme attention to detail.  Several sorts of
"evaluation" happen to a command line.

	Command SUBSTITUTION
	    `command` is called and the output substituted
	Parameter SUBSTITUTION
	    $thingies are replaced by their values
	File Name GENERATION
	    "globbing", "wild-cards".  The manual page says clearly that
	    this happens after command and parameter substitution and
	    blank interpretation.

Now when we come to input/output redirection, we are told about
	word
	>>word
and so on that "SUBSTITUTION" happens to the word before it is used.
That's *all* that happens; file name generation (globbing, wild-card
processing) is not done, and blank interpretation is not done either.
	$ y="BIG trouble"
	$ echo $y >$y
	$ ls
	BIG trouble
	fred
	$ ls $y
	BIG not found
	trouble not found
	$ rm "$y"

You can see why the Bourne shell works this way:  before command and
parameter substitution the "word" is *one* thing; blank interpretation
and file name generation could turn it into more than one thing, and
what would that mean?  The C shell handles it differently:

	% set y="BIG trouble"
	% echo $y >$y
	$y: Ambiguous.

As should be clear by now, assignment to keyword parameters is another
context where substitution is done but file name generation is not.