Negative patterns should probably not treat dots or symlinks special
facelessuser opened this issue · 2 comments
To be completely effective, negate patterns should probably not treat symlinks or dots special. It makes it difficult to negate a range like this:
positive: ./*/*.py -> negative **/test/*
It is similarly difficult with symlinks. Since negate is always applied to patterns that were already matched with dot and symlinks rules, and we are just filtering the results, negate patterns should probably match dots, special directories, and symlinks with *, [], **, ?, etc.
I'm thinking we will still exclude .. and .. I think we will enable DOTMATCH`DOTGLOB`, and not worry about symlinks in negate patterns. I think this seems reasonable.
The current exclusion behavior has always been a little confusing in the way it defaults a regular pattern. Exclusion patterns have always been a way to filter existing patterns. They mean nothing by themselves. Basically, you search for files with a pattern and provide an exclusion to filter them out.
For whatever reason, when I implemented it, I decided to have it provide the pattern ** the user only provide exclusion patterns. This was to solve the problem of what is it trying to exclude. This was the wrong solution.
** is subject to the GLOBSTAR flag. So it gives different behavior when it is enabled or disabled. Not only that, it forces a recursive match, which may surprise the user if they are use the glob command.
What it should do is assume either an empty pattern or maybe even no patterns, and simply match nothing. It is meant to augment other patterns, not be the match pattern.
Currently, in this issue, I've defaulted it to an empty string, but this may change to no pattern once I finish deciding. I've added the NEGDEFAULT to mimic old behavior as a deprecation path, but it will raise a warning.
I rather fix these kinds of things now, rather than wait till even more people start using this library.