Re: grep / sed + regex : possible bug ?
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
Reply to: