Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Boolean argument detection is too aggressive #64

Open
shadowspawn opened this issue May 11, 2024 · 2 comments
Open

Boolean argument detection is too aggressive #64

shadowspawn opened this issue May 11, 2024 · 2 comments
Labels
documentation Improvements or additions to documentation

Comments

@shadowspawn
Copy link
Collaborator

Copied from original repo. Single comment from @sampsyo with no upvotes:
https://web.archive.org/web/20200904203601/https://github.com/substack/minimist/issues/75/


Consider this tiny program that uses a single boolean flag:

var minimist = require('minimist');
console.log(minimist(process.argv.slice(2), {
  boolean: ['f']
}));

It works as expected for most arguments:

$ node foo.js -f xxx
{ _: [ 'xxx' ], f: true }

But, shockingly, if the argument happens to contain the strings "true" or "false" anywhere in the string, then the argument gets reinterpreted as an argument for the -f flag:

$ node foo.js -f xxxtruexxx
{ _: [], f: false }
$ node foo.js -f xxxfalsexxx
{ _: [], f: false }

The value of the -f flag is false in both cases, but the argument mysteriously vanishes from the _ array.

This is especially surprising if, for example, your program works fine until you happen to use a file with "true" in its name. I would expect the argument list to be left alone entirely, regardless of its content, when used with a boolean flag.

Tests run with [email protected] using Node v4.2.1 on OS X.

@shadowspawn
Copy link
Collaborator Author

I think this should be covered in the documentation, like has been done for --no-* in #48

@shadowspawn shadowspawn added the documentation Improvements or additions to documentation label May 11, 2024
@ljharb
Copy link
Member

ljharb commented May 11, 2024

This one seems like it’s worth fixing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants