feat: Print help menu on --help for all commands

[hyperupcall]

Summary

Uses a function has_help_flag to determine if should print the help menu. If it should, it prints all valid uses (from help.txt), and returns success.

These changes also change some invocations of printf to display_error (of some help text), since in other places it was used and it is more correct. These changes are only in places where no argument were passed, and the help menu is printed while exiting with code 1.

Fixes: #1330

Other Information

I saw that the asdf shell help commands were different.

In help.txt:

asdf shell <name> <version>

In command-export-shell-version.bash:

asdf shell <name> {<version>|--unset}

I assume one of them should be updated?

More generally, I think there is an issue that the help menu and its shorthands with --help can be out of sync. Should I do some restructuring so that instead of cating the help.txt file, it uses a shared variables approach? (see the hack I do for so alignment works for both the source and the output):

asdf_help() {
  ...
  printf '%s\n' "MANAGE PLUGINS
${asdf_help_plugin_add:          }      Add a plugin from the plugin repo OR,
                                        add a Git repo as a plugin by
                                        specifying the name and repo url
${adsf_help_plugin_list1:        }      List installed plugins. Optionally show"

Another approach is something I've done, where various functions with multiple printfs are called in sequence, but that is more for a help menu that looks completely different

different help menu

Usage:
    command [flags] <command> [--help] [args...]

Flags:
    -h, --help
        Print help

    -q, --quiet
        Do not log informative messages to stdout. Error messages will still be printed

Subcommand(s):
    init [--no-cd] <shell>
        Print code for a particular shell to set the proper PATH, etc.

    install [--no-cache] [--force] [name] [version]
        Install a particular tool
    ...

Or, we can just leave the changes as they are - thoughts?

[jthegedus]

I have been thinking about making a change like this for some time, so have some thoughts to share, but won't have the time to go through this issue thoroughly and share my thoughts for a few days.

[hyperupcall]

@jthegedus Wondering if you are available to take a look at this now? (P.S. thank you for merging the other PRs)

[hyperupcall]

Closing this to reduce my personal PR queue as this repository seems to not be maintained

[Stratus3D]

Hi @hyperupcall , sorry for the extremely late reply here (this PR has literal sat in an open tab of mine since you opened it).

I've been in the working rewriting asdf in Golang (in a private org fork). I think this is a good improvement, but it doesn't make sense to get this merged given that everything is changing with the Go implementation. Happy to accept a PR if the Go implementation needs a similar improvement!

[hyperupcall]

@Stratus3D Yeah I figured you were focusing your effort on the Go (previously Rust?) fork. That's why I closed all my other PRs too; But the rewrite is a bit perplexing to me as there are existing solutions such as Mise and other solutions that are by now, much more mature. In any case, once the Go implementation is public, I'll try it out and see if there is anything I can contribute;