no_args_is_help for command?

[chris-hailstorm]

When creating a MultiCommand (like a Group), there is a useful option no_args_is_help -- if set, invoking the group without a parameter or subcommand prints the help message for the group, e.g. program is equivalent to program --help.

However the same option doesn't exist for subcommands, so program subcommand produces an error message -- is not equivalent to program subcommand --help.

Is there an option I'm missing?

Thanks

[jdell64]

I'd like to use no_args_is_help in just command as well.

I added this in the core.py file... I'm still new to open source projects, so I'm not sure how to do a pull request (or even how to test it).

[jdell64]

I did a pull request. #502

[untitaker]

Hello @jdell64, sorry for the late response!

I don't think using this option would be a good idea, since it obscures the reason the usage was invalid. I'd prefer a solution a la #393, which seems like a perfect middle-ground that prevents us from adding options for every single color of the bikeshed.

At the same time just showing help sort-of makes sense for groups, although I do wish that there'd be an error message at the top, explaining why click shows the help.

[jdell64]

I was trying to emulate some old command-line applications that do this:

Linux

• ping
• sudo
• ssh

Windows

• ping
• ssh

And other examples.

To your point, not all applications do this:

• cp

There are some (I cannot remember which) that do both:

someCommand.exe
Error: missing arg0 - filename
{help text here}

[untitaker]

Click has some very strong opinions about how a good CLI should look (e.g. #108) Using it as a way of emulating another interface is going to fail badly, especially as those interfaces may not be consistent and would require Click to be inconsistent (either by default or via opt-in) as well.

[jdell64]

Does the code I submitted introduce instability or it just doesn't conform to the desired output of Click?

I haven't contributed to many OS projects, so I apologize if I missed the mark here.

[untitaker]

Your code is perfect for the thing you want to do, but I remain unconvinced that the thing you want to do is a good idea from a UX perspective. I'm also not claiming that Click's current solution is perfect, but that probably depends.

In the end it's just bikeshedding, would like to hear a few opinions from others first. @mitsuhiko @RonnyPfannschmidt

[jdell64]

Well, bikeshedding is the only way I can contribute :D

My opinion (for what its worth) is that it isn't on by default, and shouldn't really affect most users. I guess it could bog down the code base.

[davidism]

Decision made to keep current "see --help" message in #502.