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