Sdk: Bash completion for `dotnet`

[jeremymeng]

It would be nice to have completions for various dotnet commands/options.

[jchannon]

Agree , Same here https://github.com/aspnet/dnvm/issues/498

[brthor]

This would be very nice to have. Any recommendations on how to go about this?

[adrian17]

Technically all that needs to be done is add a script to debian package: /etc/bash_completion.d/dotnet

I made a basic completion file that dumbly completes command names (new, compile etc) and basic common options (--help, --verbose). For expanding it, there's a short guide here.

[willl]

Have a look at the work @nosami wrote in this repo - https://github.com/nosami/dnx-bash-completion

[nosami]

Sadly, it's a little out of date now. It could be brought up to date pretty quickly though by someone with the motivation. I'm afraid I don't use DNX any more (or C#)

Someone should build zsh completion too.

[horsdal]

Would be nice for PowerShell too ..

[thebrianlopez]

+1

[tgnm]

+1

[TheRealPiotrP]

This is being worked on as we speak. I'll try to link an issue later.

[tanaka-takayoshi]

How is the progress? I created the same issue for dotnet ef command. https://github.com/aspnet/EntityFramework/issues/5976

[TheRealPiotrP]

https://blog.jcoglan.com/2013/02/12/tab-completion-for-your-command-line-apps/ has some nice info regarding this. Both bash & zsh.

[TheRealPiotrP]

Folks, I'm curious about your thoughts on a particular aspect of this feature.

Enabling tab completion requires an install step to be completed, at least on bash and zsh. Though CLI has native installers for some platforms, we don't have these for all platforms. What's more, many folks prefer to use the CLI zip/tarball distributions to ensure a private version or to enable installation without root access.

The challenge, then, is to provide an intuitive and simple tab completion installation experience without caveats such as Your platform doesn't have a native installer, You chose to install using a zip, etc.

We have a few ideas on how to enable this experience. I'm curious what you think about them, and if a better approach exists. The basic premise is to enable the CLI to self-register its Tab Completion script without an install-time action. There are a couple of ways to do this, each with tradeoffs:

• An implicit startup-time registration. When a CLI command is executed we check for registration and perform it immediately to enable Tab Completion for all subsequent invocations
• An explicit command, dotnet enable-tab-completion, that performs the registration

I tend to prefer the first option since it does not require explicit action from users, nor does it require discovering that completion is available... it just works (tm). Given that installers often lay down tab completion scripts without prompting, this seems like a good experience. However, I've not found examples of other apps that self-register without installation so I wonder if there is some precedent for avoiding this approach.

The second part of this puzzle is how to actually accomplish the tab completion registration. At the end of the day, we need to provide some script which gets executed during shell startup. For installer-driven registrations, this happens to /etc with root permissions. Since requiring root access would be a UX pain, we could instead add a line to .bashrc or .zshrc. How would folks feel about this approach? Do the benefits of seamless registration outweigh a program automatically modifying a .*rc file?

Finally, what other approaches have folks seen that work well in similar scenarios? Is there an altogether better way?

[TheRealPiotrP]

And of course, we're looking at PowerShell as well. We just happen to be a but further in the investigation on bash & zsh!

[mishra14]

_An implicit startup-time registration. When a CLI command is executed we check for registration and perform it immediately to enable Tab Completion for all subsequent invocations_ 👍

[tanaka-takayoshi]

It's great. I also think _An implicit startup-time registration. When a CLI command is executed we check for registration and perform it immediately to enable Tab Completion for all subsequent invocations_ is good. Besides, I want an opt-out option. In the CI server, we don't want to enable tab completion usually as it takes a time to set up. My idea isdotnet --ignore-enable-tab-completion or other option can skip the implicit process.

[jonsequitur]

This feature has been available for little while now but was released with very little fanfare due to the lack of a non-manual installation experience. More feedback for Piotr's question above would be very welcome.

Details on how to enable tab completion are here: https://github.com/dotnet/cli/blob/master/Documentation/general/tab-completion.md.

[stevedesmond-ca]

Given @TheRealPiotrP's two options, I would prefer startup time registration.

My ideal solution would be to integrate it into current shell completion engines (e.g. for bash-completion, adding a file to /etc/bash-completion.d on install). My thought is that using the .deb (most likely via apt-get) is the happy path, make that as automated as possible (plus it's already running as root).

I can only speak to my own experience with Linux admins, but if someone is taking the long road to download a tar and manually extract it and either add the dir to their $PATH or making a symbolic link somewhere in their $PATH, they're probably going to want to manually setup autocompletion registration anyway (if at all).

[omajid]

I agree with @stevedesmond-ca. For anyone using .NET Core with a package manager (whether apt, brew, choco, dnf, yum or zypper) we should ensure the auxiliary items like shell completion (and other things such as man pages) get installed correctly. It's the simplest and most common use case to implement and support.

The basic premise is to enable the CLI to self-register its Tab Completion script without an install-time action.

This is going to be a bit difficult to do in a way that handles all corner cases correctly - specially not clobbering any user-customized configuration. We can't simply echo ". /path/to/completion/" >> ~/.bashrc, for example (what if root is running it? what if the user already has a variant of this in their .bashrc? what if they use a separate file/shell-framework to load up shell completions? How would we handle "uninstallation" of zips?)

I am also having trouble thinking of any other program that provides shell completion unless installed via the package manager.

I think we should provide the shell completions in our all our distributibles (they are not included in the sdk zips nor deb packages last I looked) but let users set them up if they want to use them without a package manager.

[omajid]

FWIW, it looks like we can simply copy our current bash completion file over to/usr/share/bash-completion/completions/dotnet (or equivalent) and it will get picked up and used automatically. We could easily do this in our .rpm or .deb packages.

zsh needs more work: https://github.com/dotnet/cli/issues/8923

[jasonkarns]

It looks like the homebrew cask for the SDK is also lacking the completion registration for homebrew.

https://github.com/Homebrew/homebrew-cask/blob/d79bc9f88fc8028ca03343c70dfc03582fe5aa03/Casks/dotnet-sdk.rb

FWIW: I created a brew formula in my own personal tap: brew install jasonkarns/homebrew/dotnet-completion
https://github.com/jasonkarns/homebrew-homebrew/blob/master/Formula/dotnet-completion.rb

[jasonkarns]

I have a larger concern that I just discovered: the completion scripts are not present in the tagged releases on github:

current master: https://github.com/dotnet/sdk/tree/e80cf181f715697b88f18845d095bb9b623f325a/scripts
latest tagged release: https://github.com/dotnet/sdk/tree/v3.1.401/scripts

So it's not presently possible to safely install the scripts as associated with the corresponding dotnet release.

[omajid]

This is caused by the repo consolidation/move that moved a ton of code around, not just the scripts.

In 3.1 the scripts were in cli: https://github.com/dotnet/cli/blob/release/3.1.1xx/scripts/register-completions.bash