Resolve asdf PLUGIN_NAME default command.

When calling `asdf foo` and the `foo` plugin provides a `bin/default-command`

bin/asdf

@@ -119,7 +119,7 @@ case "$1" in
     help_command;;
 
   *)
-    plugin_cmd="$(get_plugin_path "$1")/bin/${cmd_args[0]}"
+    plugin_cmd="$(get_plugin_path "$1")/bin/${cmd_args[0]:-default-command}"
 
     if [ -x "$plugin_cmd" ]; then
        exec "$plugin_cmd" "${cmd_args[@]:1}"

docs/plugins-create.md

@@ -95,6 +95,7 @@ It's possible for plugins to define new asdf commands. This way plugins can exte
 For example, a `foo` plugin might expose the command `asdf foo bar` by providing an executable file at `bin/bar`.
 If `bin/bar` is a file but has no executable bit set, then its considered a source-able bash script, and will be sourced 
 with all the functions in `$ASDF_DIR/lib/utils.sh` already loaded.
+The executable for `asdf foo` itself should be placed in `bin/default-command`
 
 A good example of this feature is the `nodejs` plugin, where people must import the release team keyring before
 installing a nodejs version. People can execute the following command without having to know where exactly is the plugin located.

test/plugin_extension_command.bats

@@ -11,6 +11,23 @@ teardown() {
   clean_asdf_dir
 }
 
+@test "asdf can execute plugin default command" {
+  plugin_path="$(get_plugin_path dummy)"
+
+  # this plugin defines a new `asdf dummy` command
+  cat <<'EOF' > "$plugin_path/bin/default-command"
+#!/usr/bin/env bash
+echo hello
+EOF
+  chmod +x "$plugin_path/bin/default-command"
+
+  expected="hello"
+
+  run asdf dummy
+  [ "$status" -eq 0 ]
+  [ "$output" = "$expected" ]
+}
+
 @test "asdf can execute plugin bin commands" {
   plugin_path="$(get_plugin_path dummy)"