Add process to add to .bash-profile for dotnet suggest script

[wli3]

prerequisite of #219

[wli3]

it is not easy to just write stuff to bashrc since depends on the distro, it could also be bash_profile. And blindly write to it could mess up user's shell config. I am thinking to make a line to let user to copy paste. And that line could be generated by some "guess" like RID and $BASH_VERSION

[jonsequitur]

Perhaps a command that adds/updates the script in the file at a specified path?

> dotnet suggest install --powershell $profile

[wli3]

(i plan to bikeshed "install" verb later)

That's similar. But this command only won't help too much. To find where the profile is the hardest part for existing copy paste solution especially for powershell. At the same time, we cannot guess it 100%. I plan to add export DOTNETSUGGESTSCRIPTVERSION to the script itself. So dotnet-suggest's help could read it and detect if dotnet sugguest install is needed and print the guessed command.

Looks like you try to use dotnet suggest and you are on ubuntu with bash. suggest script is not in your profile yet. You can run the following to add it.

dotnet suggest install --shell bash "$HOME/.bashrc"

[wli3]

As for update. I think we should check if DOTNETSUGGESTSCRIPTVERSION matches the version dotnet suggest has. And the script will have # DOTNET SUGGEST START and # DOTNET SUGGEST END to mark the beginning and the end. So we know what to delete. Any less hacky idea?

[jonsequitur]

This could maybe be solved with some additional indirection: The line of script added to the profile could be a one liner that calls out to dotnet-suggest (since it's expected to be on the path), gets the script text back from the resolved executable, and runs that. This should reduce issues arising from out-of-sync versions, frequency of profile changes, and the need for a cryptic script block in the user's profile.

[omajid]

If this is for https://github.com/dotnet/command-line-api/blob/master/src/System.CommandLine.Suggest/dotnet-suggest-shim.bash, the normal system-wide installation style is to install that script with the name of the program in a location like /usr/share/bash-completion/completions/dotnet so it gets picked up by bash automatically. This is how programs like make, vim and tar set up completions without asking users to add stuff to their .profile.

This location probably varies between distros. From what I can tell from some tests, the file name matters: a file named /usr/share/bash-completion/completions/foo is looked up for completing a command named foo.

[wli3]

This location probably varies between distros. From what I can tell from some tests, the file name matters: a file named /usr/share/bash-completion/completions/foo is looked up for completing a command named foo.

This would be a problem for dotnet-sugget. It is supposed to complete many command (who used system.commandline).

/usr/share/bash-completion/completions/ is a sudo location. And local tools(a good user case for system.commandline) are installed in $HOME and it is for per user.

[wli3]

additional indirection: The line of script added to the profile could be a one liner that calls out to dotnet-suggest

That might work, let me try

[jasonchester]

dotnet-suggest has the ability to output the script already... instead of adding the entire script into the profile the instructions should use the following.

if hash dotnet-suggest 2>/dev/null ; then source <(dotnet-suggest script bash); fi

unfortunately this is not working in bash

❯ if hash dotnet-suggest 2>/dev/null ; then source <(dotnet-suggest script bash); fi
-bash: /dev/fd/63: line 2: syntax error near unexpected token `$'\r''
'bash: /dev/fd/63: line 2: `_dotnet_bash_complete()

Completions are such a great idea and really important for users building command line applications that provide a great experience. It is frustrating how buggy it is right now and I end up turning it off.

[jonsequitur]

The ability to output the script was added to dotnet-suggest for just this kind of scenario, though piping isn't something we've tested. More likely, we would want to support something like:

> dotnet suggest install bash /path/to/.bash_profile

What other bugs have you seen? They tend to be specific to the environment. If you provide details, they can get fixed.