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

An option that allows unknown flags to be included in a varargs? #1243

Closed
henderea opened this issue Nov 8, 2018 · 4 comments · Fixed by yargs/yargs-parser#181
Closed

An option that allows unknown flags to be included in a varargs? #1243

henderea opened this issue Nov 8, 2018 · 4 comments · Fixed by yargs/yargs-parser#181

Comments

@henderea
Copy link

henderea commented Nov 8, 2018

I have a script I'm converting from ruby that allows me to run arbitrary shell commands in a special mode. I define the command as something along the lines of $0 <cmd> [args...], but if i pass an unknown flag as part of args, it gets taken out and treated like a regular flag. Is there any way I can set my script to skip parsing and validation of unknown flags?

Basically, I want a mode that treats unknown flags as regular arguments. If I run script.js ls -la ., it should have argv.cmd be 'ls' and argv.args be ['-la', '.'], rather than putting something in argv.l and argv.a. I really like the functionality of yargs, but the fact that it parses out unknown flags is making it unusable for my purposes.

I haven't managed to find anything for this by looking through the documentation and code, so does yargs not support this? And if not, can support be added?

In case you would like to see my code, it can be found at https://github.com/henderea/jse, specifically the sudo subcommand.

@henderea
Copy link
Author

henderea commented Dec 3, 2018

Has anyone had a chance to look at this issue? I should be able to have a varargs include undefined flags as-is. If the argument -l falls inside a variadic argument and isn't defined in my code, it shouldn't fail the strict check and should instead just stay in the variadic argument.

Perhaps something similar to .strict() to enable this on demand instead of by default would be the best option. Maybe call it .literal()?

@sastraxi
Copy link

sastraxi commented Jun 2, 2019

Running into this too -- trying to implement the following and there's no way to do it without this feature as far as I can tell. sastraxi/pgsh#36

@bcoe
Copy link
Member

bcoe commented Jun 7, 2019

@sastraxi @henderea I'd be open to adding this as an opt-in feature, something you configuring using .parserOptions.

I don't have too many cycles for feature work lately, but would happily accept a PR if you're interested in giving it a shot.

I can be found in chat here when I'm doing OSS on weekends:

http://devtoolscommunity.herokuapp.com/

@henderea
Copy link
Author

henderea commented Jun 7, 2019

@bcoe I've submitted a PR to the yargs/yargs-parser library (yargs/yargs-parser#181). My new code has 100% test coverage, and all tests are passing. After looking into the code, I realized that the change needed to be put in the parser library, rather than the user-facing library.

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

Successfully merging a pull request may close this issue.

3 participants