Help shown via no_args_is_help results in exit code 2, was 0

[fdavis]

fixes #1394
fixes #1486

[davidism]

Command can also have no_args_is_help. I think the error code should be 2 instead of 1 to match other usage errors.

[davidism]

Changing this caused a test to fail, but it seems to be revealing something weird about the processing, not a problem with this change. The following causes an exit code of 2, even though --help was passed so it should result in 0.

import click

@click.group()
@click.argument("obj")
def cli(obj):
    click.echo(f"obj={obj}")

@cli.command()
def move():
    click.echo("move")

cli(["obj1", "--help"])

The problem is caused here in MultiCommand.resolve_command:

click/src/click/core.py

Lines 1398 to 1407 in 0ad4e79

	# If we don't find the command we want to show an error message
	# to the user that it was not provided. However, there is
	# something else we should do: if the first argument looks like
	# an option we want to kick off parsing again for arguments to
	# resolve things like --help which now should go to the main
	# place.
	if cmd is None and not ctx.resilient_parsing:
	if split_opt(cmd_name)[0]:
	self.parse_args(ctx, ctx.args)
	ctx.fail(f"No such command '{original_cmd_name}'.")

ctx.args is empty at this point, which causes the no_args_is_help behavior. Since that matched the actual --help behavior before, the issue wasn't caught. Seems like it might be related to #473.

[davidism]

Ironically, I just closed #1323 which discussed how the processing pipeline needs a rewrite, and then re-discovered that this PR demonstrates the issue.

[davidism]

Pushed a new implementation that uses a new NoArgsIsHelpError to match how other usage messages are handled. This doesn't fix the processing issue.

[davidism]

I started looking into this before 8.1, and it's too complex to disentangle the pipeline issues right now. I have plans for the parser/pipeline, so I'll come back to this then.

[benjaoming]

Nice one @AndreasBackx 🙌