Repository navigation
Command w/o args displaying usage should return non-zero #1394
Description
Try running git, and you will see its usage. You will also receive a non-zero return code, indicating failure. This can be vital in case arguments got truncated.
Current behavior of showing usage instructions (help_text) is great!
But it should also error out with a code 1.
Example:
➜ git
usage: git [--version] [--help] [-C <path>] [-c <name>=<value>]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | --no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
(snip)
'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
➜ echo $?
1
Reference: learningequality/kolibri#5937
Activity
jcrotts commentedon Sep 13, 2019
I'm not completely understanding, can you clarify what you are asking for?
Non zero exit codes are returned in some cases, if there is a missing argument or option.
Git actually returns a 0 exit code if you call it with --help.
benjaoming commentedon Sep 13, 2019
If my
wonderful-commandis run without arguments, it should be understood as an error. But it should also output usage instructions.That's because
git --helpis understood as a deliberate command.gitis understood as a wrong command but will output usage instructions for convenience.jcrotts commentedon Sep 14, 2019
I looked at the linked issue, what specifically would you change within click.
The following seems fairly straightforward to add if your Click app doesn't throw a missing argument exception, but you still want it to return a non zero exit code.
benjaoming commentedon Sep 16, 2019
Yes, it's simple to implement, as you can see that's what we did -- but perhaps Click can add it as default behavior? I intended to open the issue to flag that it seems like a deviation from conventional behavior.
davidism commentedon Sep 16, 2019
You've only described it differing from git's behavior, not "conventional" behavior. Is there any convention or standard for this that is demonstrated by a majority of applications?
I don't see "no args is error" as any more valid than "no args printing help is expected, so not an error", so I don't currently see a compelling reason to change this.
benjaoming commentedon Sep 16, 2019
@davidism
mycommand $filename<= if$filenameis empty by mistake, then it will return 0 as if execution was successful.benjaoming commentedon Sep 16, 2019
I tested git, rsync, ssh, cp, mv, rm, ip. They all return non-zero.
layday commentedon Oct 7, 2019
This only happens with groups - invoking a (sub-)command requiring arguments, without arguments, will raise and exit with a non-zero status code. The default behaviour of a group is not to call the callback (i.e. the wrapped function) if the argument is not supplied, which presupposes that it is required. Click should exit with a non-zero status code if
invoke_without_commandis false and defer to the callback if it's true.jab commentedon Jul 12, 2020
If anyone else has trouble parsing @benjaoming's comment above, the "<=" is not meant to be "less than or equal". It's meant more like "so" or just full stop. In other words:
I do see this as one valid reason that Click's current default behavior might lead to unexpected results.
I also have seen, more often than not, widely-used command line tools print usage to stderr and exit nonzero when invoked without required arg(s).
But while changing this default in Click may help for this use case, it's not immediately obvious that it wouldn't hurt other use cases, given the wide variety of different CLIs this could affect. It would be helpful if someone could show how this change would affect other use cases.
benjaoming commentedon Jul 22, 2020
Thanks @jab , here is the example (from #1394 (comment)) of unintentional behaviour again: