Question/Proposal: How to remove inactive commands from shims

[lambdalisue]

I have a problem to use OS's builtin infocmp command when I installed miniconda3-latest with pyenv because miniconda3-latest somehow has this fundamental command...

I understand that sometimes it is better to tell users which env has a corresponding command but I usually feel this behavior is annoying. For example, I often check the command presence by [[ -x {command} ]] and it often passed even the command is not usable while the command wrapper script exists in shims.

So I would like to ask how can I remove command wrappers for commands exist in inactive envs. Or I would like to propose the way to do that.

[lambdalisue]

By the way, this issue is partially related to ContinuumIO/anaconda-issues#994 even though I don't think installing ncurses on conda's env is a good way while it overwrites OS's ncurses in conda's session...

[joshfriend]

there is a blacklist of anaconda executables that should not be turned into shims. Occasionally, anaconda adds more executables to it's bin/ which we have to filter out.

[lambdalisue]

Is there any document about that blacklist? I would like to know how to override that setting on my local system.

[joshfriend]

There's some small explanation in conda.bash.

We'd welcome a PR to expand on that and also to add whatever shims are causing your environment issues to the blacklist.

[jonathanbranam]

#1358 I added this pull request to remove infocmp from the shim list.

[native-api]

Pyenv shims now "fall through" to a system-wide command if the command is not present in the currently selected installation.
So an existing shim for a command from an inactive installation is no longer a problem.

[humitos]

I just arrived here and saw that there was a infocmp shim installed in one version of miniconda. Then, asdf/pyenv was always failing and telling me that I should enable that version to make it work. Re-shiming didn't work.

I found that version of miniconda, uninstalled it, re-shim and everything worked again! Thanks for your tips.

[native-api]

@humitos This message is now only printed if you don't have it in any of the selected versions -- AND further on PATH.
So it's equivalent to getting a "command not found" (in fact, Pyenv prints exactly that before the suggestion text) -- and as such, I don't know what else you expected 🙂