Carapace setup not working

[electriquo]

Current Behavior

I read Bash setup guide and tried to setup Carapace into my shell. Carapace didn't work for me although the its function were there

$ declare -F | grep -E '^(declare -f ){1}(get|(un)?set|_carapace){1}'
declare -f _carapace_lazy
declare -f get-env
declare -f set-env
declare -f unset-env

I was looking whether something overridden or has a conflict with Caraspace, but there was none. The only thing that worked for me, was placing the setup commands at the very end of my shell profile file.

Expected Behavior

Carapace setup could appear anywhere on the shell profile files and still get activated

Steps To Reproduce

1. Add Carapace setup (see below)
2. Start a new shell session
3. Optionally, execute declare -F | grep -E '^(declare -f ){1}(get|(un)?set|_carapace){1}' to verify Carapace setup occurred
4. Navigate to a Git repository
5. Type in git sh and press the tab key

Assumptions

1. Linux OS (also holds for macOS though the commands below are slightly different)
2. Bash shell
3. ~/.bash_profile exists, non-empty, has commands in it excluding Carapace setuo and is loaded when the user logs in

Add Carapace

The following will add Carapace setup at the first line of the ~/.bash_profile file if it is not already there

CMD='source <(carapace _carapace)'
FILE=~/.bash_profile

grep -qxF "$CMD" "$FILE" || sed -i "1s/^/${CMD}\n/" "$FILE"

Remove Carapace

The following will remove Carapace when it was added as above

sed -i '1d' "$FILE"

Version

1.0.2

OS

• [X] Linux
• [X] OSX
• [ ] Windows

Shell

• [X] Bash
• [ ] Elvish
• [ ] Fish
• [ ] Nushell
• [ ] Oil
• [ ] Powershell
• [ ] Xonsh
• [ ] Zsh

Anything else?

No response

[rsteube]

Hmm.. You've got this issue on Linux and OSX? Anything in your .bashrc that might interfere with carapace? Which Bash version have you?

[electriquo]

You've got this issue on Linux and OSX?

Yes.

Anything in your .bashrc that might interfere with carapace?

declare -F | grep -E '^(declare -f ){1}(get|(un)?set|_carapace){1}' shows that Carapace functions are there but nothing happens when trying to use Carapace (using git sh then pressing the tab key)

Which Bash version have you?

5.2.26

[rsteube]

So on both systems it works when you put it into ~/.bash_profile or call it manually in a running shell with source <(carapace _carapace)? If so I'd assume there is either some interferance with other entries in .bashrc or the shell isn't correctly detected (use source <(carapace _carapace bash)). The functions being present as you wrote should mean that the detection is fine though :thinking: .

[electriquo]

Debugging reveals that having Carpace setup line before/after the line where ~/.bash loads completion files makes the difference. There are 40 completion files that are loaded and I wonder what is the most efficient way to find which one and maybe then why there is a collision.

[electriquo]

@rsteube When I execute source <(carapace _carapace) within the active shell, then using git sh... pressing the tab activates the builtin completion of Git. But when I press tab 2 times, then Carapace completion get activated for the first time. Do you have any lead why? Maybe this is the source of the issue...

[rsteube]

Carapace has a 2-step process registering the completion:

_carapace_lazy() { # initial script registered for completion
  source <(carapace $1 bash) # source actual completion script on first tab (e.g. for git)
   $"_$1_completion" # execute the actual completion script (function) so that they are returned for the first tab as well
}

There could be something interfering with line 3 calling the old script. But I haven't encountered something like this in a long time (did in the past though).

[rsteube]

Try sourcing just the git completion in a fresh shell and see if that works on the first tab:

source <(carapace git bash)

[electriquo]

Try sourcing just the git completion in a fresh shell and see if that works on the first tab:

source <(carapace git bash)

This did not help and couldn't debug the issue

[electriquo]

Any idea how tell what conflicts with Carapace?

[rsteube]

Not at the moment.

In Fish there's an issue where the file based system completions are always loaded. So when you register a completion and then try to TAB complete the system one gets loaded and overwrites the previously registered one. I could imagine someting similar happening here, but I don't have this issue with Bash on any of my systems :thinking: .

[rsteube]

Which Linux is this? Is it possible to reproduce it in a docker container?

[electriquo]

Is it possible to reproduce it in a docker container?

I am sure it is possible, but it seems to me like lots of work. Will try to look into it and report back.

Which Linux is this?

macOS at the moment.

[electriquo]

Investigation shows clearly that if a builtin completion (such as git) are loaded after source <(carapace _carapace), then Carapace completion will not kick in for the loaded completion (such as git).

This can be easily verified, the following will not let Carapace kick in

source <(carapace _carapace)
source /usr/share/bash-completion/completions/git

Whereas, the following will let Carapace kick in

source /usr/share/bash-completion/completions/git
source <(carapace _carapace)

@rsteube Any insights?

[rsteube]

That is normal behaviour. By sourcing the completion file you are registering a different function for git.

[electriquo]

Following https://github.com/carapace-sh/carapace-bin/issues/2387#issuecomment-2131213580 and

That is normal behaviour. By sourcing the completion file you are registering a different function for git.

Then Carapace setup much occur after loading all shell completion. To guarantee this is always the case, what stated holds

The only thing that worked for me, was placing the setup commands at the very end of my shell profile file.

[rsteube]

So it is fine now?

[electriquo]

So it is fine now?

It was always fine if Carapace setup is added at the very end of the profile :) Maybe worth mentioning it in the docs, to save your and others time.

Thank you @rsteube