Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!mcvax!unido!sbsvax!greim From: greim@sbsvax.UUCP (Michael Greim) Newsgroups: comp.unix.questions Subject: Re: CSH Help -- I don't get it ... Summary: Apologies for unclear posting. Sorry. Message-ID: <595@sbsvax.UUCP> Date: 12 Aug 88 09:23:41 GMT References: <9832@eddie.MIT.EDU> <1170003@otter.hple.hp.com> Organization: Universitaet des Saarlandes, Saarbruecken, West Germany Lines: 131 Ok, Damian, my posting was unclear. Thanks for pointing it out. (I still have much to learn :-) In article <1170003@otter.hple.hp.com>, pdc@otter.hple.hp.com (Damian Cugley) writes: > / comp.unix.questions / greim@sbsvax.UUCP (Michael Greim) / Aug 8, 1988 / > > > < if "$x" =~ "stuff*" echo yes > > < alias x 'if "$x" =~ "stuff*" echo yes' > > < x > > < alias x 'if "$x" =~ "stuff"* echo yes' > > < x > > < It only prints 'yes' once -- on try three. > > It's a bug in csh or at least an undocumented strangeness. > > It may not be a bug. It *is* consistent with the rest of csh. Yes, this may not be a bug. Let's stick to that it is not a bug. ^^^^ (So nobody needs a fix, nobody has to work one out, and all versions of csh behave the same :-) > > "..." quoting prevents pattern patching when expanding filenames in > commands, so it makes sense for the same to happen when using patterns > with =~ or !~. Ok. > > > In your first example the string resulting from expanding "$x" has > > no 8 bit turned on, but the string "stuff*" has. Thus "*" is not recognized > > as a shell meta character. > > I don't think this makes much sense to me - I wonder what the person > asking the question made of it :-( . The * isn't recognised as being > magical because it is quoted (i.e. in "..."). Exactly how csh keeps > track of what's quoted and what isn't is beside the point. Sorry. > > > A fix I made some months ago and posted to the > > net took care of this bug, I think. It was listed as <486@sbsvax.UUCP> > > from 25.apr.88. But there were still some flaws in pattern matching > > which it might even be impossible to straighten out. > > I don't *think* it's a bug (I don't claim to be an expert). In the man > page for csh it says "..." prevents filename expansion, i.e. makes * > unmagical. It should've said it made it unmagic in =~ patterns too, but > that's a reasonable deduction. > > Why would it be useful for pattern-matching to work even when quoted? > How then would we turn it *off*!? If there's no bug, 'fixing' it will > only cause more problems (i.e. introduce more bugs...). I have made a modification to pattern matching, where a pattern is command- and filename- expanded like any other operand. "abc*" is a pattern matching abc, abcd, ... but "abc\*" only matches the string "abc*". Ok, it introduces more problems and its usefulness is at least doubtful. That's one of the reasons why I have not posted it. (And I could not make myself to write a small text on the differences) The bug fix I mentioned above was for another but similar problem (my, am I confused lately :-), viz.: - create files "a,b" and "abc" - try to list these two files using "{" and "}" filename expansion metacharacters as in the example below Script started on Fri Aug 12 10:48:16 1988 % ls a,c abc typescript % ls a{b,,}c ac not found ac not found abc % ls a{b,\,}c ac not found ac not found abc % ls a{b,","}c ac not found ac not found abc % ls a{b,','}c ac not found ac not found abc % And so on. The above cited fix was for this problem. Afterwards % ls a{b,\,}c produced the correct output : a,c abc The same applies to metacharacters "[", "-" and "]". This problem is about pattern matching but besides the point of this discussion. > > > BTW: > > Did you ever wonder why 'if "$x" =~ "stuff"*' does not try to do > > any filename substitution? The big question is : should it ? > > No, I didn't wonder. No, it shouldn't. 'If's are special csh keywords, > and the test part isn't a command; hence there's no reason whatsoever > why it should try to expand patterns into filenames in the test part of > an 'if'. But it expands other operands. Try : #! /bin/csh if ( Gargle* =~ "Gargle"*) then echo "1 : ok." else echo "1 : false." endif and you will see, that csh filename expands the left operand of "=~". BTW: And why is the pattern not command substituted? Does the manual say so? Should it not be possible to if ( "$a" =~ *`hostname`*) ... whereas if ( "$a" == `hostname` ) ... works ?? (You may not have noticed this, as it produces no diagnostic message.) Ok, you can circumvent it, but isn't it a bug? Or is it no bug, if it would have been documented? The manual should be extended to say some lines about patterns in csh expressions. One can adapt to a lot of strange rules if they are documented. -mg -- +------------------------------------------------------------------------------+ | UUCP: ...!uunet!unido!sbsvax!greim | Michael T. Greim | | or greim@sbsvax.UUCP | Universitaet des Saarlandes | | CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) | | ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 | | Phone: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany | +------------------------------------------------------------------------------+ | # include| +------------------------------------------------------------------------------+