You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are trying to use clikt for a command that can take a URL as an argument. This can have query parameters, but it seems like any argument with a "=" in the name is treated as an argument. For example:
class Hello : CliktCommand() {
val arg by argument()
override fun run() {
echo("Argument: $arg")
}
}
fun main(args: Array<String>) = Hello().main(args)
$ hello foo
Argument: foo
$ hello foo=bar
Error: no such option: "foo".
The docs state:
Clikt normally parses any value that starts with punctuation as an option, which allows users to intermix options and arguments. However, sometimes you need to pass a value that starts with punctuation to an argument. For example, you might have a file named -file.txt that you want to use as an argument.
However, in this case, we do not have any starting punctuation, so I don't know why it's trying to parse it as an option.
While we can ask users to use the "--" delimeter, it means that it will effectively always need to be used. This is a pretty annoying experience.
I've never seen a command that behaves this way, so I'm assuming this is a bug. If this is indeed the desired behavior, could a mechanism be provided to disable it?
The text was updated successfully, but these errors were encountered:
We are trying to use clikt for a command that can take a URL as an argument. This can have query parameters, but it seems like any argument with a "=" in the name is treated as an argument. For example:
The docs state:
However, in this case, we do not have any starting punctuation, so I don't know why it's trying to parse it as an option.
While we can ask users to use the "--" delimeter, it means that it will effectively always need to be used. This is a pretty annoying experience.
I've never seen a command that behaves this way, so I'm assuming this is a bug. If this is indeed the desired behavior, could a mechanism be provided to disable it?
The text was updated successfully, but these errors were encountered: