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

- can not be string value #15

Closed
Yesterday17 opened this issue Dec 13, 2022 · 7 comments · Fixed by #17
Closed

- can not be string value #15

Yesterday17 opened this issue Dec 13, 2022 · 7 comments · Fixed by #17

Comments

@Yesterday17
Copy link

The regex /^-/ matches -, making argument valued by - character only not available.
- is commonly used as the reference of stdin.

&& !(/^-/).test(next)

@ljharb
Copy link
Member

ljharb commented Dec 13, 2022

This line dates back to 7cced88#diff-e727e4bdf3657fd1d798edcd6b099d6e092f8573cba266154583a746bba0f346R63 - iow, it's always been in minimist (and presumably optimist, its precursor, as well).

I agree that an argument value of - should be permitted. Want to send a PR with a test case, and perhaps also a fix?

@Yesterday17
Copy link
Author

Maybe /^-./ could work?

@shadowspawn
Copy link
Collaborator

The test is done in two places, for a short option and for a long option, and I think should be the same. The pattern used in the other place is more careful and won't fire for a plain -: /^(-|--)[^-]/

&& !(/^(-|--)[^-]/).test(args[i + 1])

@milanholemans
Copy link

We are having a similar issue, we are trying to run a command with option --id "-9rMKQooUjZdxgv1qQVZYABEuw".
After parsing, it looks like:

{
  "1": true,
  "9": true,
  "i": true,
  "r": true,
  "M": true,
  "K": true,
  "Q": true,
  "o": true,
  "U": true,
  "j": true,
  "Z": true,
  "d": true,
  "x": true,
  "g": true,
  "v": true,
  "q": true,
  "V": true,
  "Y": true,
  "A": true,
  "B": true,
  "E": true,
  "u": true,
  "w": true
}

Id should be parsed as string and not as flags.

@shadowspawn
Copy link
Collaborator

@milanholemans Minimist assumes arguments which start with a dash are an option (or options) and not consumed as an option argument. A fix for single dash won't change this behaviour.

To get the parsing you expect, use an embedded option value with an = like:

--id=-9rMKQooUjZdxgv1qQVZYABEuw

Then a possible dash on the start of the id will not change the parsing.

@milanholemans
Copy link

Minimist assumes arguments which start with a dash are an option (or options) and not consumed as an option argument

I assumed this was the problem indeed.

To get the parsing you expect, use an embedded option value with an = like:

This seems to be working indeed, awesome! Thanks for the fast feedback @shadowspawn!

@topaz1008
Copy link

topaz1008 commented Dec 28, 2022

Hello.

I also have the same problem, and the suggestions here don't solve it 100%.
I am using Windows10 and Node.js v18.12.1

To get the parsing you expect, use an embedded option value with an = like:

This does not work if the value contains a space. you need both an =, and quotation marks " around the parameter.
e.g.

> node test.js --command="-c:v copy"
{ _: [ 'copy' ], command: '-c:v' }

Describe the exact steps which reproduce the problem

// test.js
import minimist from 'minimist';

const options = minimist(process.argv.slice(2));
console.log(options);

Running the following command gives this output:

> node test.js --command "-c:v copy"
{ _: [], command: true, c: ':v copy' }

Expected output:

> node test.js --command "-c:v copy"
{ _: [], command: '-c:v copy' }

When writing out the command using BOTH an = (equals) and quotation marks, it works as expected.
e.g.

> node test.js --command="-c:v copy"
{ _: [], command: '-c:v copy' }

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

Successfully merging a pull request may close this issue.

5 participants