isaacs/minimatch

a glob matcher in javascript

minimatch's Issues

Any plan to support user home aka `~`?

The question is in the title. Sometimes I find it practical to rely on some data securely stored in the user directory (like ~/.ssh/my-package.pem).

can I match a directory with the drive name as like c:\w-jobs\**\*.coffee

Hi,
can I match a directory with the drive name as like c:\w-jobs*__.coffee.

thanks

Directories can contain square brakets

This is continuation of issue, started in gulp-watch. Minimatch translates [ and ] as class pattern, but in fact you can execute mkdir such[dir] and create folder with name that includes brackets. Seems like minimatch is lacking of ability to escape square brackets, because writing \[ does not help.

Add "files" entry in package.json to ignore everything but listed there

In this package I suppose only minimatch.js is required when installed in production mode, so you just need to add this in the package.json:

{
  "files": [
    "minimatch.js"
  ]
}

See https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package for more info.

Thanks.

won't match input containing / correctly

minimatch("_video_", "*video*")   // true
minimatch("/video/", "/video/")   // true
minimatch("/video/", "/video*")   // true
minimatch("/video/", "*video/")   // false ???
minimatch("/video/", "*video*")   // false ???

`npm test` shows 0 tests

$ npm test

> [email protected] test c:\Documents and Settings\apenneba\Desktop\src\minimatch
> tap test

total ................................................... 0/0

ok

0.3.0

npm says the latest version is 0.3.0 while package.json in master says 0.2.14.

Can you push the missing commits and tag?

"**/" pattern doesn't match "./" path part

This seems like a bug to me, intuitively, but I don't see it addressed in the docs anywhere:

var minimatch = require("minimatch");

minimatch("foo/bar.js", "**/foo/**")     // true
minimatch("./foo/bar.js", "./**/foo/**") // true
minimatch("./foo/bar.js", "**/foo/**")   // false

Shouldn't the last example return true because **/ should match ./?

Ref. cowboy/node-globule#11

Brace expansion does not support number padding

in bash, echo {00..01} => 00 01 。

in minimatch, mm = new Minimatch('{00..01})' got:

{ options: {},
  set: [ [ '0' ], [ '1' ] ],
  pattern: '{00..01}',
  regexp: null,
  negate: false,
  comment: false,
  empty: false,
  globSet: [ '0', '1' ],
  globParts: [ [ '0' ], [ '1' ] ] }

browser version

Hi! Why publish browser version on npm? It just increased size of package.

Give some examples

It would help to have a handful of example patterns at the top of the readme (each with examples of paths they match and do not match), to show how things like globstars, brace expansion and parentheses work. I imagine this is the main thing people come here for, and the readme barely touches on it.

Simpler exclusion pattern when globbing

When I try to exclude a directory (and its files) from a glob, I need to write out the pattern like this:

[
  'app/**',
  '!app/{_tmp,_tmp/**}'
]

Just using this:

[
  'app/**',
  '!app/_tmp/**'
]

would copy over the directory, but will not contain any files. While using this:

[
  'app/**',
  '!app/_tmp/'
]

would copy over _tmp and its files.

Is there any way to simplify this pattern? It seems like just using '!app/_tmp/**' should be sufficient to exclude the directory entirely.

(Referencing gulpjs/gulp#165)

Glob patterns with `**` are not properly converted to regular expressions

> minimatch('node_modules/foobar/foo.bar', 'node_modules/foobar/**/*.bar')
> true

> var re = minimatch.makeRe('node_modules/foobar/**/*.bar', { nocase: true });
/^(?:(?=.)node_modules\/(?=.)foobar\/(?:(?!(?:\/|^)\.).)*?\/(?!\.)(?=.)[^/]*?\.bar)$/i
> re.test('node_modules/foobar/foo.bar')
false

*foo* doesn't match foo/bar

It does match with glibc's fnmatch.

package.json malformed JSON?

I got an error while running yeoman's angular generator, yo angular, which in turn installs minimatch as a dependency. The exact error has to do with parsing minimatch's package.json file which it doesn't seem to think is valid JSON.

I tried require-ing package.json in a separate node instance and it seemed to be OK, so not sure if this is really a bug in minimatch or npm's fault despite it professing it's not in the error message.

If anyone can reproduce on their end I can take a more detailed look, or if anyone knows why this may be happening we can can this issue.

Backslashes not supported as path separators

If I use minimatch (or glob) with forward slashes in my pattern, everything works as expected. But if I use backslashes as path separators in my pattern, minimatch always returns false -- it never matches anything. This means I can't use path.join to build my pattern string (even though it's an obvious choice), because path.join uses backslashes on Windows.

minimatch should work correctly with patterns that use the current platform's path separator. (It'd be even better if it always accepted either kind of path separator, regardless of the current platform.)

Example:

mm = require('minimatch');

// Simple match. Returns true, as expected.
mm('foo/bar/baz', 'foo/**/baz')

// Same match, but now using path.join.
// Expected: Should return true.
// Actual: returns false (on Windows).
path = require('path');
mm('foo/bar/baz', path.join('foo', '**', 'baz'))

// Equivalent to the previous example.
// Should return true, but instead returns false.
mm('foo/bar/baz', 'foo\\**\\baz')

Fixing this would probably just be a matter of making minimatch normalize the test string to use forward slashes instead of backslashes.

pattern `**/.svn/**` doesn't work as expected when using `minimatch()`

if I do find . -path "**/.svn/**" it will log all the files inside all .svn folders, no matter how deep they are, shouldn't minimatch() also match these paths?

js/lib/.svn/tmp
js/lib/.svn/tmp/prop-base
js/lib/.svn/tmp/props
js/lib/.svn/tmp/text-base
js/lib/.svn/tmp/text-base/foo.js.svn-base
js/lib/.svn/tmp/text-base/bar.js.svn-base
js/widgets/templates/.svn/all-wcprops
js/widgets/templates/.svn/entries

the weird thing is that if I use minimatch.makeRe() it generates the proper RegExp... simple test:

var minimatch = require('minimatch');
minimatch('js/lib/.svn/tmp', '**/.svn/**'); // false
minimatch.makeRe('**/.svn/**').test('js/lib/.svn/tmp'); // true

am I missing something? I ended up using the makeRe() since it does work as I expect.

Make library usable by browsers without a module loader

Would you consider accepting a patch which would make this module usable in browser-side code without using a module loader? Apologies if you've expressed a position on this in the past that I've missed.

Can minimum npm version be added to package.json?

"brace-expansion": "^1.0.0" is not supported in all versions.

consider a PR to replace brace expansion?

If you're open to it, I'd like to do a PR to replace the current brace expansion logic with braces.

The primary reason I'd like to make this PR is b/c we use minimatch and glob extensively, so - for selfish reasons - I'm attempting to make it easier for me (and hopefully others) to contribute by modularizing/streamlining some of the code.

I already converted everything locally and all related tests pass. Braces has better test coverage if you want to see those tests as well. I also created some basic benchmarks:

I'd be happy to do a PR for your review first if you're open to this.

Globstar breaks if folder names start with .

I suspect this is the same bug as #30 but can't be certain:

var pattern = '**/.DS_Store';

minimatch( '.DS_Store', pattern );      // true
minimatch( 'foo/.DS_Store', pattern );  // true
minimatch( '.foo/.DS_Store', pattern ); // false

NPM looks for 0.2.14, but it doesn't exist in this repo

Library is broken after last release. It doesn't work on Windows.

Pathes are not parsed properly.

minimatch doesn't match contents of directories

From eslint/eslint#1069.

Unsure if this is intended or not, so opening this just to make sure it's been considered (couldn't find any tests).

.gitignore will match all of the contents of a directory even without a **glob. The following would all be (mostly) equivalent:

foo/bar
foo/bar/
foo/bar/**

This isn't the case for minimatch. The first two will only match the directory itself, while the last one will match all the contents.

extglob implicit *

In node repl:

var m = require('minimatch'),
f1 = 'name/asdf.md',
f2 = 'nameasdf/asdf.md',
f3 = 'ok/asdf.md';

pattern = '!(name)/*.md'

m(f1, pattern, {nonegate:true}) // false
m(f2, pattern, {nonegate:true}) // false
m(f3, pattern, {nonegate:true}) // true

$ grep version node_modules/minimatch/package.json 
  "version": "2.0.1",
$ node --version
v0.10.33

Is this expected?

Match specific files in directory

I'm tying to match particular files in directory

I'm trying to use path/to/directory/{ajax.js,data.js} pattern but doesn't work. Would it be able to use such a patter?

negative matches unclear

I want to

match "design/**/*"
except "design/templates/*"

maybe something like this could work

"design/!(templates)**/*"

but that's really not clear from the docs.

Strange context switch around line 215 in make function

I hit this error [TypeError: undefined is not a function] in the Minimatch constructor.

  console.log(this);

  // make the set of regexps etc.
  this.make()  // <-- the bomb is here

around line 165. that log gave me this

{ options: { debug: true, sync: true },
  set: [],
  pattern: './src/jsdoccer.js',
  regexp: null,
  negate: false,
  comment: false,
  empty: false }

fyi, it was called from node-glob.

Build tests

Any reason why the build tests were paused? This library is downloaded quite a bit (46k/day according to npmjs). Could we get those re-enabled and/or the tests updated?

Regex with dot: true does not match original

Please take a look at this:

var minimatch = require('minimatch');

var Minimatch = minimatch.Minimatch

var mm = new Minimatch("a/*/b", {dot: true})
var re = mm.makeRe();

var files = [
  "a/./b",
  "a/../b",
  "a/c/b",
  "a/.d/b"
]

var withRegex = [];

files.forEach(function(file) {
  if (file.match(re)) {
    withRegex.push(file)
  }
})

console.log(withRegex)
// => [ 'a/./b', 'a/../b', 'a/c/b', 'a/.d/b' ]

var withOutRegex = [];

files.forEach(function(file) {
  if (minimatch(file, "a/*/b", {dot: true})) {
    withOutRegex.push(file)
  }
})

console.log(withOutRegex)
// => [ 'a/c/b', 'a/.d/b' ]

And if I understand this correctly, the regex version is actually correct?

Cant match paths that includes dirs that starts with "."

[email protected]

> minimatch('libs/my-lib/config/conf.js', 'libs/**');
true
> minimatch('libs/my-lib/.config/conf.js', 'libs/**');
false

is it normal behavior?

matchBase has no effect on makeRe

> var m = require('minimatch')
undefined

// expected behavior
> m('/asdf/asf.py', "*.py", {matchBase: true})
true
> m('/asdf/asf.py', "*.py")
false

// these REs are the same
> m.makeRe("*.py", {matchBase: true})
/^(?:(?!\.)(?=.)[^/]*?\.py)$/
> m.makeRe("*.py")
/^(?:(?!\.)(?=.)[^/]*?\.py)$/

looking through the code, this makes sense after the fact.
https://github.com/isaacs/minimatch/blob/master/minimatch.js#L892

makeRe() doesn't match same things as original object

Example:

var filter = "{*,**/**/**}/foo/{*,**/**/**}";
var path = "c:/aaa/foo/bbb.js";

var mm = new minimatch.Minimatch(filter, {matchBase: true, noext: true});
var re = mm.makeRe();

console.log(mm.match(path));
console.log(path.match(re));

Result:

true
null

The original Minimatch object matches this particular path, but the generated regexp does not.

README needs some links to manpages or regex patterns

I'm honestly lost as to what is available to me and how to negate a pattern and I've been using GNU/Linux for the last decade and have seen all sorts of hairy regexp patterns and can't make heads or tails what I can use here.

How about some links to manpages or regex patterns or some more examples or something?

minimatch cache key computation seems wrong

  var cacheKey = pattern + "\n" + Object.keys(options).filter(function (k) {
    return options[k]
  }).join(":")

This creates a cachekey with the key names of all truthy options rather than their values (since it is using filter and not map).

Causes issues when two calls have the same pattern but only differ in the value of options.cwd

I guess it should be something like:

  var cacheKey = pattern + "\n" + Object.keys(options).map(function (k) {
    return k + '=' + options[k]
  }).join(":")

Incorrect slash substitution on Windows platform

In minimatch.js, function Minimatch back-slash characters in the pattern get replaced by forward-slashes when running on Windows platform. This isn't necessary since glob requires that only forward-slashes are used in paths. It is also wrong because patterns can contain back-slashes. For example it breaks 'npm help npm' on Windows (no man pages are found) because help.js, line 66 uses a pattern with a back-slash that mustn't be converted to a forward-slash (which is then interpreted as a path separator and breaks the pattern).

I suggest not to convert slashes in minimatch because it would be hard to distinguish slashes in paths from slashes in patterns but to leave path conversion to the caller, e.g.
var manroot = path.resolve(__dirname, "..", "man").split("\\").join("/")
in help.js, line 59.

minimatch('tmp/public/app/css/main.css', 'tmp/*')

resolves as false .... I suppose this should result true

npm ERR! building projects with subdependencies on minimatch in node v0.8.26/OSX

I first encountered this issue in my Travis builds of https://github.com/shutterstock/armrest for node v0.8.26. After installing nvm and v0.8.26, I am able to replicate locally and for multiple other projects.

The thing I cannot figure out about the error is that minimatch@'^0.3.0' as I understand it should match against 0.3.0

npm ERR! Error: No compatible version found: minimatch@'^0.3.0'
npm ERR! Valid install targets:
npm ERR! ["0.0.1","0.0.2","0.0.4","0.0.5","0.1.1","0.1.2","0.1.3","0.1.4","0.1.5","0.2.0","0.2.2","0.2.3","0.2.4","0.2.5","0.2.6","0.2.7","0.2.8","0.2.9","0.2.10","0.2.11","0.2.12","0.2.13","0.2.14","0.3.0"]
npm ERR!     at installTargetsError (/Users/Rubikzube/.nvm/v0.8.26/lib/node_modules/npm/lib/cache.js:719:10)
npm ERR!     at /Users/Rubikzube/.nvm/v0.8.26/lib/node_modules/npm/lib/cache.js:641:10
npm ERR!     at saved (/Users/Rubikzube/.nvm/v0.8.26/lib/node_modules/npm/node_modules/npm-registry-client/lib/get.js:138:7)
npm ERR!     at Object.oncomplete (fs.js:297:15)
npm ERR! If you need help, you may report this log at:
npm ERR!     <http://github.com/isaacs/npm/issues>
npm ERR! or email it to:
npm ERR!     <[email protected]>

npm ERR! System Darwin 13.1.0
npm ERR! node -v v0.8.26
npm ERR! npm -v 1.2.30

Add some examples

It would be useful if the readme had a handful of pattern examples at the top (just a few, to illustrate how to do brace expansion, negation, etc). Currently it just dives into very in-depth documentation, but I would guess most people visiting this page are just looking for a reminder of the syntax.

Invalid ranges cause throw

Invalid ranges like [z-a] are allowed in globs, and interpreted as their literal value, but this module throws.

minimatch.makeRe ignores flipNegate

It appears minimatch.makeRe("*1.js", {"flipNegate":true, "matchBase":true}) for {a.js, a1.js} still returns a1.js instead of a.js when using it with filename.match(miniRegexp).

Is it ignoring it, or am I missing something?

Negating patterns not working

Patterns using extglob negating groups never matches. e.g. *.!(js)

Problem with exclusion syntax

I am currently facing a problem using minimatch syntax through gulp for a simple task.

Here is how my files are organized :

public/
____app/
________file4.txt
________js/
____________admin/
________________files1.txt
________________files2.txt
____________otherfolder/
________________files3.txt
____________file4.txt

I am trying to get all files included in app (only file4.txt in my example) and in the app/js/admin folder (files1.txt & files2.txt).

Here is my glob syntax :

['public/app/js/admin/**/*.txt', '!public/app/js/**', 'public/app/**']

With this command, it only return file4.txt and an empty js folder.

Thanks for your help !

braceExpand() removes !!

braceExpand('!!') is giving me an empty string instead of itself back

Incorrect extended glob results

When an extended glob pattern ends in a special character, it seems that non-matching strings can be erroneously matched. E.g.:

> var m = require('minimatch')
> m('testing', 'test')
false // ok
> m('testing', 'test@(x*)')
false // ok
> m('testing', 'test?(x*)')
true  // :(
> m('testing', 'test*(x*)')
true  // :(

As a sanity check, Bash thinks differently:

$ touch testing 
$ ls test?(x*)
ls: cannot access test?(x*): No such file or directory
$ ls test*(x*)
ls: cannot access test*(x*): No such file or directory

From the output with debug: true, it looks like the special is getting translated outside of the parentheses when it should be inside:

> m('testing', 'test?(x*)', { debug:true })

… resulting pattern: /^(?=.)test(?:x)?[^/]*?$/

Compare with:

> m('testing', 'test?(x*y)', { debug:true })

… resulting pattern: /^(?=.)test(?:x[^/]*?y)?$/

TypeError when using * in pattern

I'm having trouble using *.txt pattern for matching. Same error seems to apply to any pattern containing * or ?. This is on a Windows system (node 0.69, minimatch 0.1.4, lru-cache 1.0.5):

var mm = require("minimatch");
mm("something.txt", "*.txt");

This results in:

TypeError: Object /^(?!.)(?=.)[^/]*?.txt$/ has no method 'match'
at E:\workdir\node_modules\minimatch\minimatch.js:173:18
at Array.map (native)
at Minimatch.make (E:\jaketest\node_modules\minimatch\minimatch.js:170:13)
at new Minimatch (E:\jaketest\node_modules\minimatch\minimatch.js:108:8)
at minimatch (E:\jaketest\node_modules\minimatch\minimatch.js:74:10)
at repl:1:1
at REPLServer.eval (repl.js:80:21)
at repl.js:190:20
at REPLServer.eval (repl.js:87:5)
at Interface. (repl.js:182:12)

negative matches problem for .min.js like paths

I am trying to filter files by extnames:

var minimatch = require('minimatch');
console.log(minimatch('foo/bar.min.js', '*.!(js|css)', {matchBase: true})); // true
console.log(minimatch('foo/bar.min.js', '!*.+(js|css)', {matchBase: true}));    // false

Are the results expected?

Should this fail?

minimatch.makeRe('*((*.py|*.js)|!(*.json))das*(*.js|!(*.json))')

I get this error:

SyntaxError: Invalid regular expression: /^(?!\.)(?=.)(?:\([^/]*?\.py|[^/]*?\.js)*\|(?:(?!(?:[^/]*?\.json)\das(?:[^/]*?\.js|(?:(?!(?:[^/]*?\.json$)[^/]*?))*)[^/]*?)\)das(?:[^/]*?\.js|(?:(?!(?:[^/]*?\.json)$)[^/]*?))*$/: Unterminated group
    at new RegExp (native)
    at Minimatch.parse (/home/zane/test/node_modules/minimatch/minimatch.js:618:16)
    at Array.map (native)
    at Minimatch.<anonymous> (/home/zane/test/node_modules/minimatch/minimatch.js:174:14)
    at Array.map (native)
    at Minimatch.make (/home/zane/test/node_modules/minimatch/minimatch.js:173:13)
    at new Minimatch (/home/zane/test/node_modules/minimatch/minimatch.js:128:8)
    at Function.minimatch.makeRe (/home/zane/test/node_modules/minimatch/minimatch.js:627:10)
    at repl:1:11
    at REPLServer.defaultEval (repl.js:124:27)

I think it has to do with this code:

   var openParensBefore = nlBefore.split('(').length - 1
    var cleanAfter = nlAfter
    for (i = 0; i < openParensBefore; i++) {
      cleanAfter = cleanAfter.replace(/\)[+*?]?/, '')
    }
    nlAfter = cleanAfter

It removes all closing parentheses, even if they encapsulate another group

2.0.8 -> 2.0.9 regression for weird nested *(!(pattern))

The upgrade to 2.0.9 from 2.0.8 (which happened automatically for us on install with gulp -> vinyl-fs -> glob-stream -> minimatch) introduces a failure generating valid regexes for our pattern src/**/*(*.json|!(*.js)). Granted, that pattern is a bit wonky, but it was working before and now it is not.

I have a PR with the test added -- it passes on 2.0.8 but showcases the error in 2.0.9. I didn't pull against your master since it doesn't include a solution, just a failing test.

play-co#1

@isaacs - let me know if you want me to PR this against your master

I would expect the pattern /foo/* to match /foo/bar/baz

At the moment it doesn't seem to, is this expected behaviour or is it a bug?

Cheers

John