Thank you for your contribution. This would need to be refactored to only fail on an actual error condition, e.g. the $ lolcommits --option-that-doesnt-exist from your example.

I'd like to do what git does, e.g. the base command with no_args displaying help is not an error condition, but an expected behavior.

$ git > /dev/null && echo $?
0

Thus, in order to support this, we would need to actually detect and display error message on unknown arguments (rather than just ignore them, which we do now), and use an error code only in that case.

$ git --shazam > /dev/null
Unknown option: --shazam
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>]
$ echo $?
129

(This may be easier to do as part of #259 when we rely on Methadone for option parsing).

I'd like to do what git does, e.g. the base command with no_args displaying help is not an error condition, but an expected behavior.

Hmm.. what version of git do you run? On 2.3.0;

$ git > /dev/null; # Outputs general usage information
$ echo $?
1

@williamboman it looks like the exit code is intentionally changed by hub, which I wrapped git with on my system (and then forgot about).

Been thinking through this one a lot, detailed response incoming after I type it all up.

Having a single exit code indicating successful/non-erroneous executions is a bit troublesome.

I generally like to think that when a shell command actually executes an action, or is able to unambiguously determine what the user wants, it should exit with 0, else >0.

So been looking into this one a lot. Some thoughts & notes:

• Most applications that just display help on no args return 0 as their exit
  code. In fact, git was the only one in the informal test of a dozen apps
  I just did that I could find that does return a nonzero value for this case.
• A nonzero exit code implies some sort of error. Git considers not providing
  an option an explicit error, whereas most applications seem to consider the
  "request for help" prompt as a non-error UX condition.

But -- even if considering argc == 0 an error condition, using the generic "something went wrong" exit code of 1 seems problematic, since as you alluded to, it means we can't distinguish between an "expected error" and a "something unknown went wrong." This is apparent in the modified integration tests where in this PR we would start to check for exit code 1 when the point of the tests is to assess that nothing failed.

On that note, I am actually going to consider submitting a patch request to git itself changing the "no op" exit error code from 1 to something non-generic (ala the custom 128/129 exit codes they use for other error conditions). This has nothing to do with lolcommits, but I'm curious to see what they think.

Now, back to lolcommits.

I've been reviewing the CLI code and the current UX behavior for no_args is actually wrong. We can note from TODO that the desired behavior is actually to report the lolcommits installation status for the current repository. At this point, the behavior is intentional and not an error.

Therefore, two new tasks for lolcommits:

• I need to actually implement the contextual helper above. I've started a new
  issue to track it at lolcommits with argc == 0 should report install status for current repo  #264.
• We should error on opts that are not actually understood, and return an
  error code as exit condition. I started a new issue to track this at Passing unknown opts to lolcommits CLI should produce an error. #265.

Both issues are probably going to be easier to tackle as the CLI handler continues to get refactored and cleaned up (the second in particular will end up likely creating duplication until #259 is tackled.)

Thanks for your patience on my turning what started as a simple issue into a complex one. 😎

Thanks for your patience on my turning what started as a simple issue into a
complex one. 😎

Makes things more interesting, the more you know :)!

You definitely seem to have given it a lot of thought and done quite extensive research, so I'm gonna start off with just closing this as there, evidently, are different & better implementations identified for the future.

Most applications that just display help on no args return 0 as their exit code. In fact, git was the only one in the informal test of a dozen apps I just did that I could find that does return a nonzero value for this case.

The only command I tested was actually just git. The exit code for git doesn't even seem to be very motivated.

On that note, I am actually going to consider submitting a patch request to git
itself changing the "no op" exit error code from 1 to something non-generic
(ala the custom 128/129 exit codes they use for other error conditions).
This has nothing to do with lolcommits, but I'm curious to see what they think.

Will be interesting to see the discussion if you do. I personally couldn't find a credible consensus anywhere on how to determine and when to use non-0 exit codes in cases like this.