Bernd Eggink wrote:
Linda Walsh schrieb:
I keep confusing the path-matching regular expressions with
string-matching expressions and keep getting disappointed when I'm
re-reminded of the limitation...:-(
There should be no difference between path-matching and string-matching
expressions. Normally even nested extended patterns work with string
matching. But, in fact, !(...) appears to not work like one would
expect. The only case that looked correct to me is the trivial one
${x//!(*)}, which leaves $x unchanged.
I'm not sure whether this is a bug or I (we) miss something.
Interestingly, ksh behaves the same way. Can anybody clarify this?
---
Perhaps due to other failures, I haven't always had luck in the
with the *() !() ops due to quirk in the way they work...
Reading in the manpage, the section ordering is minorly
confusing at first glance...
Parameter Expansion
Command Substitution
Arithmetic Expansion
Process Substitution
Word Splitting
Pathname Expansion
Pattern Matching
Quote Removal
....
-----
In my copy of the man pages, Pattern matching is indented an extra
level making it look like it's under Pathname Expansion and only
applies there....but if people say it works outside of Paths...
well...must be so! :-)...darn manpages!
You are right about the !() not working as one would expect...
I thought:
p="myswitch1 myswitch2 myswitch3"
then
p=${p/!(myswitch2)}
I _hoped_ would match every thing in "p" except "myswitch2",
i.e. "myswitch1 myswitch3", which (guess I didn't think this
through too well) I wanted to leave "myswitch2" as the only
thing left in $p; A bit too creative with my pattern matching.
Hey...whatever happened to the "Do what I want" operator???
