Re: DEP-5: file globbing
Steve Langasek <email@example.com> writes:
> On Thu, Aug 12, 2010 at 06:18:24PM -0700, Russ Allbery wrote:
>> I would prefer to use the same syntax as .gitignore, since it already
>> deals with all of the complicated cases of matching files in particular
>> paths versus a file by that name anywhere in the tree and does so in a
>> well-specified way.
> Is http://www.kernel.org/pub/software/scm/git/docs/gitignore.html an
> accurate description of the .gitignore syntax as you understand it?
> I find several features here that are suboptimal:
> - Patterns are one per line. While this sidesteps the question of escaping
> embedded spaces, it also consumes a lot more vertical space, reducing
> human readability.
Yeah, I'm not horribly happy with that.
> - I don't think we want to support negation of patterns; any pattern
> negation could instead be expressed as a separate stanza afterwards that
> overrides the previous one.
Uh, kind of. It's always *possible* to do that, but that can turn into a
more complex way of expressing which files are involved in an exception
with overrides. Consider:
Files: extra/* !extra/foo.[ch]
Without an exclusion syntax, you now have to reiterate the Files: * stanza
in an additional specific stanza for Files: extra/foo.[ch]. I don't know
if the additional complexity is worth it, but it does address a problem.
(And this is not an uncommon pattern of licensing changes in source
packages in my experience. It happens when upstream incorporates code
from another project and then drops in some glue files to make it work
with the rest of their project.)
> - Use of a leading slash to anchor a pathname to the toplevel package
> directory is an unusual and non-intuitive convention that definitely adds
> complexity to the implementation of any tools that map Files: globs to
> the actual files.
You're using ./ now instead of /. I'm not sure I see the big difference
or the added complexity, but okay.
> For my part, I think DEP-5 is already on the right track regarding
> globbing syntax, but badly needs improvement of the standards language.
I find the current description in DEP-5 sub-optimal because it assumes I
know exactly how find -name and find -path behave and the differences
between them, which I don't. The find man page is reasonably clear on
-name, but as clear as river mud on -path.
It may be that a better explanation that doesn't reference the find manual
page will remove my concerns here.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>