Hi, i just installed app-shells/bash-completion-20060301, and it installs the following file: /etc/profile.d/bash-completion But that isn't worth anything, since in my /etc/profile it says: for sh in /etc/profile.d/*.sh ; do if [ -r "$sh" ] ; then . "$sh" fi done This version of /etc/profile is from sys-apps/baselayout-1.11.14-r5 The file should be called /etc/profile.d/bash-completion.sh instead of /etc/profile.d/bash-completion
I just saw, that i'm instructed to add [ -f /etc/profile.d/bash-completion ] && . /etc/profile.d/bash-completion to my bashrc Well, but isn't /etc/profile.d for files that are automatically loaded by /etc/profile? In addition, there is bash-completion-config to enable/disable things globally/user-wise - so i don't see any reason, why /etc/profile.d/bash-completion shouldn't be renamed to /etc/profile.d/bash-completion.sh and therefor be loaded automatically.
No it should be disabled by default and only enabled if the user wants it. As for bash-completion-config (which is deprecated in favor of eselect's bashcomp module) , it is only for enabling/disabling third party completion scripts (those installed into /usr/share/bash-completion) and has nothing to do with bash-completion proper. Closing this as WONTFIX.
*** Bug 142316 has been marked as a duplicate of this bug. ***
*** Bug 145360 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > No it should be disabled by default and only enabled if the user wants it. As > for bash-completion-config (which is deprecated in favor of eselect's bashcomp > module) , it is only for enabling/disabling third party completion scripts > (those installed into /usr/share/bash-completion) and has nothing to do with > bash-completion proper. Closing this as WONTFIX. Then shouldn't it be moved out of the /etc/profile.d directory? It would be like storing optional environment variables under /etc/env.d...
*** Bug 172553 has been marked as a duplicate of this bug. ***
*** Bug 181819 has been marked as a duplicate of this bug. ***
*** Bug 193167 has been marked as a duplicate of this bug. ***