Isn't the defer useful here? IIRC deferring the exit was useful to make sure other defer and error handlers run, right? Or does that not apply here?

Oh good catch, that's a nice one that I forget to comment on the PR.
I kept this change in a single commit so it can be easily reverted in case.

IIRC deferring the exit was useful to make sure other defer and error handlers run

what you said applies for deferred actions created in the current scope (i.e. the current running function and its callers), but since the main function, basically, does only command line parsing all the defers are instantiated inside "Commands" and when the control returns back to the main function all the internal defers are already out of scope and executed. Since the main function doesn't use defer I opted to skip the defer os.Exit construct.

The drawback is that new defers may be added in the main function in the future and it would be more future-proof to keep the defer os.Exit construct instead. Personally I prefer the "classic" behavior of the "exit" function, where the execution of the program is terminated immediately.

Another approach may be to make the main function just call sub-functions and convert the result into an exit code, something like:

func main() {
    if err := parseCommandLine(); err != nil {
        exitWithError(err);
    }
    if err := runCommands(); err != nil {
        exitWithError(err);
    }
    os.Exit(0)
}

func exitWithError(err error) {
    var exitCode int
    // [...convert error into an exitCode...]
    os.Exit(exitCode)
}

I guess you could even use a more simple approach where the effective main function can just return an exit code, just like we know from C:

func main() {
    os.Exit(realMain())
}

And then the realMain() function just does what it needs and returns an exit code?

Yup that's another way too, BTW my preference is to handle everything with golang's error until the very end and use the main function to convert it into an error code. BTW I guess we can work this out after merging this PR :-)

This seems unexpected to me - I wouldn't expect a function called "printCompleteError" to exit the current process. I guess the name should be changed? Or can this exit be removed when implementing the exit-related changes discussed elsewhere?