Cocona icon indicating copy to clipboard operation
Cocona copied to clipboard

Can't use negative numbers as argument of a command

Open filipevitoria opened this issue 4 years ago • 4 comments

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!

filipevitoria avatar Feb 19 '22 19:02 filipevitoria

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.

filipevitoria avatar Feb 20 '22 01:02 filipevitoria

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.

honguyenminh avatar Mar 11 '22 14:03 honguyenminh

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.

mayuki avatar Mar 14 '22 17:03 mayuki

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

pespinho avatar Mar 15 '22 20:03 pespinho