Can't use negative numbers as argument of a command
Greetings mayuki!
When trying to use negative numbers as argument of a command, the argument is interpreted as an option because of "-". Giving a error message of "Error: Unknown option". For example:
var app = CoconaApp.Create();
app.AddCommand("c-to-f", ([Argument] double celsius) =>
{
var x = Basics.CToF(celsius);
Console.WriteLine($"The value of {celsius} ºC in Fahrenheit is: {x}");
});
app.Run();
When executing the program in the console with:
dotnet run -- c-to-f -40
I receive the error message:
Error: Unknown option "4"
Is there any way to circumvent this issue?
Thank you for your great work!
Hello, just found out that I can use "--" to mark end of options and then I can use negative numbers normally as arguments. Nevertheless, it may be useful to consider something as argument when the number of strings passed in the terminal matches the number of required arguments.
What if the user do something like --optionA argA --optionA anotherArg?
I would expect it to override the previous one, and anotherArg will be passed to optionA. Another way to handle this is to output an error saying something along the line of "duplicate option".
If Cocona do the override way, we can't have something like what you're proposing. But if we're currently doing the "unique arguments only" way then yeah it might be possible to just stop parsing options when all options have been parsed.
However, I don't like this idea, because of inconsistency. If we have something like that, how do we know from a glance whether -3 is an option or an argument? If this feature was added, the user would have to check the help/documentation to know how many options are available, count how many are in their command, and then minus them out to see what -3 is. That's bad design.
If you want to pass that as argument, consider something else like wrapping them around quotes or something like that. That's how non-numeric-only args are usually passed around in the terminal.
This issue is troubling. For example, one approach would be to treat the value as an Argument if none of the options have numeric names. In this case, it is necessary to decide how to treat ./myapp --foo -123 --bar, ./myapp -123 --foo and ./myapp -0x1234.
I am also concerned about the complication of changing the behavior only in certain cases.
Of course I understand that the current behavior is inconvenient when dealing with negative values.
Hello mayuki,
would that be possible to escape numeric arguments by putting them inside of parenthesis?
For example:
In ./myapp --foo (-123) --bar -123 would be an argument, but
in ./myapp --foo -123 --bar it would behave like the current implementation