Wildcards in data-files don't work with filenames containing multiple dots

[bos]

(Imported from Trac #794, reported by guest on 2011-01-22)

The Hoogle cabal file reads:

data-files:
    resources/_.js
    -- surely a Cabal bug that this isn't picked up by *.js
    -- but that hoogle.js is matched
    resources/jquery-1.4.2.js
    resources/jquery.cookie.js

It seems that the filename a.b.ext doesn't get picked by the wildcard _.ext.

-- Neil Mitchell

[bos]

(Imported comment by @dcoutts on 2011-01-22)

From the user guide:

A limited form of * wildcards in file names, for example data-files: images/*.png matches all the .png files in the images directory.

The limitation is that * wildcards are only allowed in place of the file name, not in the directory name or file extension. In particular, wildcards do not include directories contents recursively. Furthermore, if a wildcard is used it must be used with an extension, so data-files: data/* is not allowed. When matching a wildcard plus extension, a file's full extension must match exactly, so *.gz matches foo.gz but not foo.tar.gz. A wildcard that does not match any files is an error.

So currently this is deliberate, that ".gz matches foo.gz but not foo.tar.gz". It has the unfortunate side effect that ".js" does not match "jquery-1.4.2.js". In this case "1.4.2" is not really a bunch of extensions but part of the name. On the other hand, "jquery.cookie.js" is exactly the sort of thing the test is there to avoid.

Perhaps it's not a problem at all and the behavior should be reversed. Are there any cases anyone can think of where it would be misleading/dangerous, where a wildcard would accidentally pick up more files than was really intended (especially e.g. generated/temp files).

[bos]

(Imported comment by guest on 2011-01-24)

Many of those restrictions seem reasonable. I think the only one I'd change is that *.ext means all files ending ".ext", not all files ending ".ext" that don't have a '.' in the filename. I understand the desire about foo.gz, but who would expect *.gz not to match foo.tar.gz? That seems completely counter intuitive.

-- Neil

[bos]

(Imported comment by guest on 2011-01-24)

Btw, jquery.cookie.js is a standard .js file, and if you asked for it's extension I would describe it has having extension .js. jquery files are often named with jquery.nameofthething.js for extensions.

[bos]

(Imported comment by @dcoutts on 2011-01-24)

Mm, I'll consider changing it for the next major version (perhaps only with a change in the "cabal-version" field, so we do not change the behavior of older packages). See also #722.

[hdgarrood]

+1 for this, I just spent half an hour trying to work out why half of my JS files weren't coming across. Should I submit a pull request?

[23Skidoo]

@hdgarrood Yes, patches are always welcome.

[BardurArantsson]

It seems rather bizarre that Cabal should behave this way given that almost(?) every single other program out there which does globbing does it differently. Surely the principle of least surprise should prevail here?

Any chance of getting this merged any time soon?

(Yes, I've also wasted 15-30 minutes on this recently :).)

[tibbe]

If this matches standard shell globs, I'm fine with this getting merged.

[BardurArantsson]

I don't know if there's a "standard" for shell globs, but shell globs do have more features. (E.g. {} and [].)

As far as I can tell from the code this should at least make Cabal's globbing a proper subset of shell globbing.