Default to exit code 2 on help message

[Qix-]

When a command fails because it's misused and shows the help message instead of executing normally, it should never fail with exit code 0 as that will improperly foul things up if the command is executed in an automated way (i.e. a script or make).

The convention is code 2, which means "misuse".

[sindresorhus]

Then you need to change it to process.exit(typeof code === 'number' ? code : 2);

Otherwise if the user tries to use 0 it will go to 2, which is wrong.

[sindresorhus]

@Qix- ⬆️

[Qix-]

👍

[sindresorhus]

You need to update the docs too.

[sindresorhus]

Hmm, we don't really know what the user is going to use the method for though.

[Qix-]

I would imagine that's an edge case. If anything we could add a third argument for an output stream to write to and have it default to process.stderr.

[sindresorhus]

@Qix- No, I meant that the user might use showHelp() in another scenario than misuse.

With your change here, it also exits with 2 when running $ foo --help. Is that really desirable? Both $ node --help and $ python --help exits with 0.

[Qix-]

Right; 2 doesn't always mean misuse but it's used as a human indicator.

With --help, there's no convention there really. It should, in theory, error out since if --help is in a script (unlikely but possible) it's probably being misused and thus should halt further execution because the program did not execute in a 'successful' way.

[sindresorhus]

@Qix- What is "success" though? I would consider showing the help when I asked for it with --help success. Same with --version. Do you have any source on this? I'm genuinely curious. I always feel this is so unstandardized, tools do pretty much what they feel like.

[Qix-]

Success means the main functionality of the utility has executed without error*. The main functionality in almost all cases isn't displaying a help message.

Put it this way:

my-program: main.o
    gcc -o $@ $<

main.o: main.c
    gcc -v -o $@ -c $<

Ignore the fact that GCC doesn't error on version, but this is something I've seen quite a few times. -v on gcc means version, not verbose (misused flag). In this case, the error message is going to be about main.o being missing since the latter gcc call completes with a 0 return code, telling the build system that it was successful, when in fact it only printed version information and returned.

Not only is that flow incorrect (the latter call was not well-formed and thus the linking step shouldn't execute at all) but it makes future error messages quite cryptic. Plus, if this was a huge tree there's the potential for a lot of re-compilation after fixing the error (albeit a bit rarer).

All of this can be applied to set -e as well.

---

*Also consider the fact a lot of this is semantics of the concept of "success" and thus is slightly subjective. 💃

[sindresorhus]

It seems like the problem here is using short flags, not just misuse. If you would instead use long flags, which are more readable, you wouldn't have this problem.

I tried out a lot of different binaries on my Mac and very few exits with other than 0 on --help and --version.

I agree it should exit with 2 on showHelp(), but I have yet to see enough evidence for doing it on --help.