On Wed 19 Mar 2003 04:17:54 +0000(+0100), Axel Schlicht wrote: [...] > So I put the above list into a file called x > x : > blaba/Name/aaa > blaba/Name/aaa/1 > blaba/name/aaa/2 > blaba/Name/bb > blaba/Name/bb/3 > blaba/Name/Ccccc/5 > blaba/Name/Cc&DD > blaba/Name/Cc&DD/2 > > but > cat x | grep '/Name/[^/][^/]*' > yields > blaba/Name/aaa > blaba/Name/aaa/1 : _/_1 not in regex, strange > blaba/Name/bb > blaba/Name/bb/3 : _/_3 not in regex, strange > blaba/Name/Ccccc/5 : _/_5 not in regex, strange > blaba/Name/Cc&DD > blaba/Name/Cc&DD/2 : _/_2 not in regex, strange > > however and quite strangely > cat x | grep '/Name/[^/][^/]*$' > as well as > cat x | grep '^.*/Name/[^/][^/]*$' > > deliver the correct result, namely > blaba/Name/aaa > blaba/Name/bb > blaba/Name/Cc&DD > > but what does $ (EOL) have to do with it. > > Looks like a bug in grep.
No, it's not a bug. Regular expressions match substrings, not entire lines, unless constrained by anchors (^ or $) [1]. Without the $ anchor, the [^/]* matches as many non-/ characters as it can, and no more. The next / and any subsequent characters are ignored. However when followed by the $ anchor, the [^/]* must match non-/ characters all the way to the end of the line. This looks like a correct solution. Does it look any less strange now? [...] [1] Actually it's application-dependent: grep and sed match substrings, whereas expr, for example, implicitly anchors its REs. -- Cheers, Clive -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
