Include bash tab completion for commands

[ggilder]

From @suan on March 1, 2012 17:30

This just struck me as something very useful and practical to include as a feature. I'm only very vaguely familiar on how bash tab completion works, so I have no idea of the work it would involve. If its a significant effort though I might be willing to help - its something that I've always wanted in my scripts!

Copied from original issue: tj/commander#41

[ggilder]

That's a great idea - I'm not really familiar with setting up bash completion either. If you want to take a stab at it that would be awesome.

[ggilder]

From @shumkov on May 22, 2012 8:19

https://github.com/mernen/completion-ruby

[ggilder]

From @shumkov on May 22, 2012 8:19

http://itshouldbeuseful.wordpress.com/2011/11/30/custom-bash-auto-completion-using-ruby/

[ggilder]

From @slnovak on November 25, 2013 4:7

👍

[ggilder]

From @deepak1556 on December 24, 2013 14:0

https://github.com/antirez/linenoise, works for most of the terminals out there.

[ggilder]

From @tuxjobs on June 6, 2014 12:26

👍

[ggilder]

From @simonweil on January 19, 2015 21:43

👍

[pghalliday]

I want this! :)

But seriously I think we need to differentiate 2 use cases. I think the original request is simplest and I interpret to mean that when I'm typing my command at a bash prompt, pressing tab tells bash to list the valid options.

The second use case, for which https://github.com/antirez/linenoise might be used (@deepak1556) would be to have tab completion on HighLine prompts (ie. while running your app). That, I think, is more involved.

On the first use case, there are lots of ways this can be acheived through simple bash scripts etc. A good article that shows how to do it for bash and zsh is here.

The missing link is an option to list the completions. This could be very useful if added as a built in global option to commander as is done with -v, -h and -t. After all commander knows all the valid commands. As used in the linked article, --cmplt seems name spaced well enough and if possible I would avoid giving it a short form.

So I suggest that a --cmplt default global option is added that will print a space separated sorted list of possible completions. Note it will have to not fail on invalid commands. eg.

my-commander-app g --cmplt

could return (made up list of valid commands)

generate get grab

and

my-commander-app generate --cmplt

could return (made up list of valid sub commands)

template magic

etc...

[pghalliday]

As a bonus, commander init (or a new command) could also be updated to generate standard completion scripts for known shells :)

Together with another default global option --initpath as described in the linked article to load the correct completion script. Then all a user would need to do is add something like this to their shell profile after installation.

which my-commander-app > /dev/null && . "$( my-commander-app --initpath )"

might even be able to do this without generating any additional files if the command returned the script contents and is eval'd instead of sourced

[pghalliday]

Ok, I've been playing with this and have a solution that works for me.

First I tried the approach described above - it was easier to do with commands than options. ie:

# to plug into completion script
my-command complete CURRENT_LINE CURRENT WORD

# to generate the completion script
my-command completion-script [ALIAS]

The problem was that in my case the complete command was too slow for tab completion (I think mainly due to ruby start up time). It worked but it was annoying as it took about a second or longer to respond. Then I had a brainwave, I didn't need the complete command. Instead I just kept the completion-script command, generating a completion script using the following ERB template

_<%= command %>_complete()  {
  local commands=(
  <% subcommands.each do |subcommand| %> "<%= subcommand %>"
  <% end %>)

  COMPREPLY=()

  local word="${COMP_WORDS[COMP_CWORD]}"

  if [ "${COMP_WORDS[1]}" == "help" ]; then
    local entered=("${COMP_WORDS[@]:2}")
    local index=$(($COMP_CWORD-2))
  else
    local entered=("${COMP_WORDS[@]:1}")
    local index=$(($COMP_CWORD-1))
  fi

  local matches=()
  for command in "${commands[@]}"; do
    local components=($command)
    if [ ${#components[@]} -ge ${#entered[@]} ]; then
      local entered_prefix=${entered[@]::$index}
      local command_prefix=${components[@]::$index}
      local component=${components[$index]}
      if [[ "${entered_prefix[@]}" == "${command_prefix[@]}" && "$component" == "$word"* ]]; then
        matches+=("$component")
      fi
    fi
  done
  local completions="${matches[@]}"

  COMPREPLY=($(compgen -W "$completions" -- "$word"))
}

complete -o default -F _<%= command %>_complete <%= command %>

Here the <% command %> is the optional ALIAS (which I default to the command name) and <% subcommands %> I get from defined_commands.keys (which is included via Commander::Methods).

The generated script also supports multiword commands (it would be much simpler if it didn't) and defaults to matching files when there are no other matches.

To enable bash tab completion I then add the following to my .bashrc

eval "$(my-command completion-script)"

It adds a bit of time to the shell startup (again about a second), but if that bothers me I could equally do something like:

my-command completion-script > ~/.my-command/completion.sh

then add the following to .bashrc

source ~/.my-command/completion.sh

Which would be as good as instant (although it might need to be rerun after updates to my-command)

I suspect a zsh script would be similar but I don't use zsh so I aint gonna write one ;)

If I can get my head round the unit tests and stuff here, I may submit a pull request :)