search

dotnet / command-line-api

Command line parsing, invocation, and rendering of terminal output.
https://github.com/dotnet/command-line-api/wiki
MIT License
3.35k stars 376 forks source link

Add support for "default verb" #2325

Open notofug opened 5 months ago

notofug commented 5 months ago

CommandLineParser supports "default verb" which is a nice feature.

Can this be added to System.CommandLine or is there a way to achive same effect already?

elgonzo commented 5 months ago

is there a way to achive same effect already?

The "default verb" is roughly akin to the root command in System.CommandLine. Just configure the root command to behave the way you want, e.g., to behave in a way you consider being the "default verb"...

notofug commented 5 months ago

Yes.. but any options/arguments added to root-command seem to extend to all 'sub-commands' as well (--help will list them also for any subcommand since they are at root) Maybe that can be worked around also, but I dont see an obvious way

KalleOlaviNiemitalo commented 5 months ago

In 2.0.0-beta4.22272.1, that should be controlled by whether you use Command.AddOption(Option) or Command.AddGlobalOption(Option).

Similar control is not available for arguments, though.

elgonzo commented 5 months ago

@KalleOlaviNiemitalo

regardless of the help output @notufug got (which suggests they are using AddGlobalOption), there is an issue that is not easy to resolve.

Using AddOption vs. AddGlobalOption only affects the allowed positioning of options in the CLI invocation and how they will be handled but not whether they are allowed in CLI invocations using sub commands.

As an example, let's say you have two commands foo and bar with these options:

app foo -a -b
app bar -x

Now, following my earlier advice, you make the root command equivalent to foo, e.g., foo becoming the "default command":

app -a -b

But doing so will also make this CLI invocation legal without error message:

app -a -b bar -x

something that is not desired when trying to use the root command as a "default command" for foo, and which i didn't consider when making my suggestion :-(

notofug commented 5 months ago

Similar control is not available for arguments, though.

Right ; this was my use-case and what I ran into

Anyway; thank you guys for advice and having this in mind as you decide how things progress đź‘Ť

KathleenDollard commented 4 months ago

I'm not sure I understand. Is it that you want these to be equivalent:

app -a -b
app foo -a -b

while, not allowing -a or -b if a different subcommand is used? IOW, not allowing:

app -a -b bar

I am curious as to when this would be helpful and whether there are any commonly used CLIs that allow this. I think it would often obscure intent.

If we had ubiquitous tab completion (I am a dreamer), would it still be important? IOW, is it just to avoid typing or is there another reason?

notofug commented 4 months ago

Yes what I was looking for was a way to be able to say : app -a -b and app bar -c

As it is now I believe the -a -b would unconditionally/automatically apply also to subcommand 'bar' (which is unwanted)

Anyway, I moved on and you are welcome to close or down-prioritize this request as nothing is suffering from it really

BurningEnlightenment commented 3 weeks ago

My use case for this functionality is a small devtool created for a singular task. It also offers a config subcommand (think of it like git config). The main task is used frequently (~2 per workday) while my coworkes rarely need to adjust the config. Furthermore the executable is aptly named and repeating the taskname or naming the subcommand do feels… wrong?