Micah Cowan <[EMAIL PROTECTED]> writes: > Yes, but -R has a lesser degree of control over the sorts of > pathnames that it can constrain: for instance, if one uses > -Rmyprefix*, it will match files myprefix-foo.html and > myprefix-bar.mp3; but it will also match notmyprefix.js, which is > probably not what the user desired.
Are you sure? It certainly wasn't designed that way. Your example should only exclude files beginning with "myprefix". >> It was supposed to be a DWIM thing. > > Where "what I mean" is what? :) Suffix when no wildcards are used, pattern when they are. > My question is: what use cases are there in which one would want to > exclude directories, but not files that match that pattern? I don't know. The reason directories are matched separately from files is because files often *don't* match the pattern you've chosen for directories. For example, -X/etc should exclude anything under /etc, such as /etc/passwd, but also /etc/foo/bar/baz. Since '*' in shell-like globs doesn't match '/', it is impossible to write a glob expression to match all files arbitrarily deep under a directory. > I see the utility of a general matcher against file names in > general; I'm not sure I see much utility of a separate option to > match against just directories. I hope the above clears it up. Choosing a matcher that doesn't special-case '/' might be sufficient. > How much potential harm would it cause to replace the current > behavior of -X to do the equivalent to Josh's --exclude-files? It will break usage such as the above "-X/etc" example.
