[darcs-users] Error on systems with case insensitive filesystems

Petr Rockai me at mornfall.net
Mon Oct 26 15:11:00 UTC 2009


Jason Dagit <dagit at codersbase.com> writes:
> What does (^|/) match?  Similarly, (\.[0-9]+|)$ is odd to me.  I just looked at
> the pcrepattern, regex, and re_format man pages on linux and the only meaning
> for | that I could find is to separate two or more alternatives.  I did learn
> that character classes should be preferred over ranges for portability
> (although, I don't see how an implementation could screw up on [0-9] and still
> be a correct implementation).
(^|/) would, using normal POSIX extended regex semantics, match either the
start of a string, or a slash. That is basically a path component delimiter
(i.e. it would match start of any path component, including the first one).

> Is it possible that the second | in the pattern for core files is erroneous?
>  Perhaps the linux posix library for regular expressions ignores the error (or
> maybe it's not even an error) while the os x implementation complains?
It's not an error, since empty regexp is completely legal, and matches an empty
string. And | is defined as (nondeterministic) choice between two regexen, so
it is OK to say (something|) (which is either "something" or nothing).

I suspect that the failure may very well be a genuine OSX bug. Trying a few
such regexps with egrep may shed some light into the issue.


More information about the darcs-users mailing list