Adding bash completion, for now only "-n" completes with available namespaces

[nicob87]

Closes #367

based/stolen from:
https://github.com/kubernetes/kubectl/blob/master/pkg/cmd/cmd.go#L293

It requires "kubectl" to be installed.

To give it a try just:

$ make build-cmd #build skupper cli
$ source <(./skupper completion) #source the autocompletion script
$ complete -F __start_skupper ./skupper #hack to make autocompletion work for "./skupper" also (normally it works for "skupper")
$ #try it!
$ ./skupper -n <tab> <tab> #autocompleting flag as first argument
default          kube-node-lease  kube-public      kube-system      private-http-1   private-mongo-1  public-http-1    public-mongo-1
$ ./skupper service -n <tab> <tab>  #autocompleting flag after calling a subcommand
default          kube-node-lease  kube-public      kube-system      private-http-1   private-mongo-1  public-http-1    public-mongo-1
$ ./skupper  <tab> <tab> #verify it is still working for normal subcommands
bind              connect           delete            init              service           unexpose          
check-connection  connection-token  disconnect        list-connectors   status            version           
completion        debug             expose            list-exposed      unbind 

[ajssmith]

What should the assumption be in an openshift environment (e.g. oc might be present but not kubectl)?

Would adding list to pkg/kube/namespace be an alternative?

[nicob87]

basically to auto-complete, bash executes "some executable", it may be anything, in this case we are executing "kubectl -n ..." we could execute "skupper -something" or build a particular new skupper executable like "skupper-completer" orrr whatever option we want.
Will take a look now if from bash I can "try" with "oc" and if fails, then try with "kubectl", which I think it is totally possible.

[fgiorgetti]

@nicob87 I would suggest writing the bash_completion in a separate .sh file,
which would make it way easier to maintain as we go.

Then we could tweak the build command for the skupper binary to include a
build-time variable that points to the bash_completion.sh file, like:

go build -ldflags "-X main.BashCompletionEncoded=`cat bash_completion.sh | base64 -w 0`" ...

Then inside skupper.go, you could decode it as:

bashCompletionFunction, err := base64.StdEncoding.DecodeString(BashCompletionEncoded)

Not sure if shell will impose some limitation, but if it works, might be worth trying.

[fgiorgetti]

I tested it locally using a 65k shell script and it worked just fine.

[nicob87]

mmmm and that works for windows and macos? (windows does not have a cat, to begin) will investigate options anyway...
awesome review!

[nicob87]

maybe just the "bash_completion_func" variable definition to a dedicated *.go file is a simple solution, if you want that file to be a ".sh" I think we should "read" that file from our go code, but, this makes a dependence and a possible runtime error, on a .sh file, which I do not like so much ...

[fgiorgetti]

The dependency exists only at build-time, after that it no longer exists, but a separate go file just with the constant
might also work.

[fgiorgetti]

@ajssmith @grs one comment here (just for tracking). Once we move to go 1.16 we
could use the new go:embed feature to load shell content directly into the go variable
at build time, so this way we can actually keep the bash completion script separately.

[fgiorgetti]

Closing as issue #574 has been raised to track this proposal.