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
StringsOpt can not start with dashes #108
Comments
Hm - seems to me you missed the "--" seperator? From README in Section https://github.com/jawher/mow.cli#spec-strings ... The -- operator can be used to automatically treat everything following it as arguments. In other words, placing a -- in the spec string automatically inserts a -- in the same position in the program call arguments. This lets you write programs such as the POSIX time utility for example:
|
The thing is that -- is not the correct solution. It's not an argument but a parameter, as you can see in the example I provided. To give a real-world example:
(removed some options, but you should get the gist) The issue is with |
Moritz @mpldr I am sorry, I do not get what you expect. Shouldn't it
so let you call
Just as I would expect it from documentation? |
No, a call would be something like:
or
|
Ah, ok, got it. Will it work already if you use parenthesis?
while
if the files exist on command call. |
The problem is not the vim version, it just served for illustration. The interesting part is the |
Yes, for sure, got all from previous posts! I just wonder and asked if the parenthesis will already help to function StingOpts. So, I asked for the sequence part:
only, and if that will already work and StingOpts detects the args correctly also without an equal sign If I got it right from your posts, this will work, correct?
But also with parenthesis and without the equal sign? |
Because of how (most) shells work, unfortunately this does not change anything. The quotation marks (I guess by parenthesis you mean them) are only used by the shell to call the process and determine where an argument starts. The quotation marks themselves are not added to the process's arguments. An easy way to try it out would be to run: package main
import "os"
import "fmt"
func main() { fmt.Println(os.Args) } // the quotation marks would be printed here as well |
Ok, got that also - for sorry I just look if something will allow the parser to catch the second value after Maybe that will be stayed safe thru the shell?
Its not the solution - just as a test if the parser currently would recognize those correctly |
here is what it looks like to the program: and the actual program tells me:
|
Well, thanks for feedback. Did I get it correctly, that even the params do not work for the forwarded So if you would drop the (") inside your golang mow.cli app then the call for If so, the parser needs a patch to identifiy |
I mean… technically it would be possible to remove this, but I am not a fan of special behaviour and this might very well cause some issues. While there might not be a "correct" answer on this, there might be a "best solution"… (I mean… I documented this behaviour with my program but just wanted to bring it up) |
If you want to supply additional options to pass to another program the syntax is limited.
Assuming that the option
--args
takes in these arguments and no one-character-alternative has been set, the=
is required.Meaning the following:
I can understand the reason for this but still feel this bahaviour to be inconsistent.
The text was updated successfully, but these errors were encountered: