Skip to content

Loading…

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

Open
bos opened this Issue · 11 comments

7 participants

@bos
Haskell member

(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
Haskell member

(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
Haskell member

(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
Haskell member

(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
Haskell member

(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
Haskell member

@hdgarrood Yes, patches are always welcome.

@hdgarrood hdgarrood added a commit to hdgarrood/cabal that referenced this issue
@hdgarrood hdgarrood Fix file globbing with multiple dots (#784)
Setting the "data-files" field in a .cabal file to pull in
"resources/*.js" would previously not work for any file containing more
than one dot, for example "resources/jquery-1.9.1.js".

This commit changes this behaviour so that a glob counts as a match,
provided that its extension is a suffix of the filename. So, if
resources/ contains foo.js and foo.bar.js:

* "resources/*.js" will match both "resources/foo.js" and
  "resources/foo.bar.js"
* "resources/*.bar.js" will match "resources/foo.bar.js" but not
  "resources/foo.js"

It should be noted that I've only tested this by calling
matchFileDirGlob in ghci -- I'm fairly new to Cabal, and can't see how
to test it properly.
1511acc
@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
Haskell member

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.

@23Skidoo 23Skidoo modified the milestone: Cabal-1.22, Cabal-1.18
@mietek

Halcyon supports declaring additional data-file for use at run-time with the HALCYON_EXTRA_DATA_FILES option, using standard GNU bash globbing syntax.

See Haskell Language for an example of declaring static website content as data files.

@mietek mietek referenced this issue in mietek/halcyon
Open

Add and improve glob-based options #39

0 of 2 tasks complete
@Ericson2314 Ericson2314 added a commit to Ericson2314/clash-compiler that referenced this issue
@Ericson2314 Ericson2314 Add missing black box templates as data-files so they get packaged
Cannot use wildcards for this until
haskell/cabal#784 is fixed
ed39a87
@ttuegel ttuegel modified the milestone: Cabal-1.24, Cabal-1.22
@BardurArantsson

It seems that this is essentially a duplicate of #2522 (given the discussion therein). Close?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.