On Sat, 2002-04-20 at 19:46, Harry Putnam wrote: > >> In the context of the original post, the comparison was to perl regex. > > > > Perl searches for a regex in a string, rather than matching a pattern on > > a string. > > I disagree, and I think this is the hub of the matter. Regex always > match a pattern. That is what regex do. One may search with a regex, > true enough but the regex always matches a pattern.
Some applications differentiate between "search" and "match" operations, and nothing about the regex spec prevents them from doing so. Arguing that a regex is "always matches a pattern" doesn't change the intended behavior of those applications. In the case of "find", the limitation is simple to understand: consistency. The -name argument doesn't match substrings, and neither does -regex. The regex supplied must match the entire path, beginning to end, just as the argument to -name has to match the whole filename. > > That's sorta up to the tool that provides the regex match/search. It's > > not uncommon to differentiate between a search and a match. > > Since you've pointed to man 7 regex as the authority on regex, can you > find this distinction explained there? > > The distinction was invented in this thread. I don't think you will > find mention of it in the documentation you point to: > ... > > One might conclude from the above that if it doesn't act like egrep or > at least ed. It isn't posix. It *is* posix. The specification for regex describes only the format of the regular expression, and not what they must match, or how they are used by applications. "find" matching a regex on an entire path, rather than a substring, is not in any way contrary to the posix regex specification, because such use is *outside* of the spec. All of the regex specification is available for use as arguments to -regex.
signature.asc
Description: This is a digitally signed message part
