-
Notifications
You must be signed in to change notification settings - Fork 9
Problem when option is substring of other option #94
Comments
If anyone else runs into this, I'm currently using the following workaround 😂 const envFromFileIndex = process.argv.indexOf('--env-from-file', 2)
if (envFromFileIndex > 0 && envFromFileIndex < process.argv.length - 1) {
process.argv.splice(envFromFileIndex, 1)
process.argv[envFromFileIndex] = '--env-from-file=' + process.argv[envFromFileIndex]
} |
Interesting :) Another less invasive workaround would be: const args = neodoc.run(...)
if ((args['--env'] && args['--env'][0] == '-from-file') || args['--env-from-file']) {
// ...
} This works because if the user explicitly binds like this |
Does it seem reasonable to disallow this altogether? |
That won't work with them both at the same time though? 🤔 https://github.com/LinusU/scandium/blob/master/lib/tasks.js#L39-L45 Indeed that would be nice. It could still start with Is it currently supported to do |
neodoc/src/Neodoc/ArgParser/Argument.purs Lines 151 to 161 in af8ad85
So, yes, that's the current behaviour and mirrors that of short options. What do you propose? From my perspective the easiest would be to remove the entire case above. |
That's neat. I've never used options like that, not that useful I think and it's also hard to read 🙂 Yes, I think it makes more sense to support more combinations of options rather than short options. @LinusU ? Let's say you had a flag called |
Not entirely, you still need to specify the flag to take an argument. Also it would only consume a single argument, unless you specify that the argument is to be repeated:
But regardless, I agree that this is counter-intuitive. I think removing that case would be a better user experience, but I'll have to do a major version bump. Will make the update shortly. |
Found another thing that is a bit wonky related to this. We added an arg called --name-postfix, we also have --name.
Will tell me there's no option called --name-postfix. Using it with explicit binding works, |
Are you able to share the usage string so I can see what's going on? While I am surprised about the error message you are getting, you won't get around having to use an explicit binding if the value looks like a flag. |
Ah, thats true 👍 I'll see My bad, it actually said "option requires argument" 🙈 So that's correct Shouldn't |
I've updated the code, it would be really helpful if you could lend a pair of eyes over the changes to the testcases, to make sure there's no oversight of anything: d6f2a0e. I've also published a prerelease version to npm for you to test out under |
Awesome! I added a comment over there for the test cases I couldn't see. I'll try updating to that version and see if it works like expected, thanks! |
Awesome, I've added a few more test cases as well, just to be sure |
|
Ok cool, the new behaviour is now available in |
Thanks for fixing it 🙏 Love this lib! |
😍 wow Awesome, to see this resolved so quickly, on vacation now but will take a look in a few days 🙌 |
I'm running into a little problem with one option that is an extension of the name of another option. I think this is best explained with an example:
Trying to use as such:
Results in:
When I expected it to parse into:
The text was updated successfully, but these errors were encountered: