Please pardon me if I mixed this up myself, but I think that the bash-completion package does not install itself correctly. It appears to expect the contents of /etc/profile.d/ to be sourced at login, which -- at least my system's -- /etc/profile -- does not do! So effectively, bash-completion won't be activated! I had to add the appropriate commands in /etc/profile manually. Another thing is that the /etc/profile.d/bash_completion script does not check wheth bash has been run as /bin/sh, in which case it will be POSIX compatible and does not support functions, causing the script to fail with syntax errors! To fix this, I changed the shell code to the following: | # Configure bash completion. | bash=${BASH_VERSION%.*}; bmajor=${bash%.*}; bminor=${bash#*.} | if [ "$PS1" ] && [ $bmajor -eq 2 ] && [ $bminor '>' 04 ] && \ | [ -f /etc/bash_completion ] && \ | [ "$POSIXLY_CORRECT" != "y" ]; then | . /etc/bash_completion | fi | unset bash bmajor bminor The interesting part is the check whether $POSIXLY_CORRECT is not equal to "y".
/etc/profile.d/bash_completion is not sourced automaticaly. You need to add this manualy into /etc/profile. The ebuild informs about this: einfo "Add the following line to your ~/.bashrc to" einfo "activate completion support in your bash:" einfo "[ -f /etc/profile.d/bash-completion ] && source /etc/profile.d/bash-completion" Currently i don't think about chaning this way. /bin/sh already rejects variable handling like " bash=${BASH_VERSION%.*} ". Anyway would it even set variables like BASH_VERSION? sh don' have this.
Well, fair enough. I just wonder whether /etc/profile.d is a good place to install it then, because the path _suggests_ it would be executed automatically! Perhaps /etc/skel would be better? Anyway, it's probably not that important ... No big deal. As for /bin/sh: On my system, the /bin/sh _is_ a bash, but it's a bash that's operating in POSIX-compliant mode. A true Bourne shell would probably choke at the shell code already (one more reason to change the code!), but the POSIXLY_CORRECT bash works fine -- except when it comes to function declaration. Here it will abort with an error.
I just started the bash with "bash --posix -l" and it sets POSIXLY_CORRECT=y and then i sourced /etc/bash_completion. It works fine with the generic bash_completion release. Ok, set doesn't list the functions but completion works well. All errors i get are from the "gentoo" specific completion commands: bash: `_rc-update': not a valid identifier bash: `_gcc-config': not a valid identifier bash: `_java-config': not a valid identifier bash: `_opengl-update': not a valid identifier Thos are only from /etc/bash_completion.d/gentoo. I think that needs to be fixed rather than disabling it in complettly. Problem is i'm not the one who writes that gentoospecific completion so i have to forward it to the author and hope he fixes it.
I don't like skel because it is only for $HOME and i don't want it sourced in my home. I want it global on my box (matter of taste). Personaly i think not automaticaly executing /etc/profile.d is a design flaw but this issue is at the wrong place. It's a generic profile issue. Personaly i even use this in /etc/profile # Append any additional sh scripts found in /etc/profile.d/: for file in /etc/profile.d/* ; do if [ -x $file ]; then source $file fi done (I activate scripts with +x and deactivate them with -x ofcourse the if-check can be removed and everything will be sourced) But as i said, automaticaly sourcing /etc/profile.d is not under my control anymore.
Posix wont allow dashes in function names. That's why all gentoo specific functions failed. The author of the gentoo specific function sent an update with works. Starting "bash --posix -l" then ". /etc/bash-completion" works without error. The automated sourcing of /etc/profile.d is not under my control and does not belong to to a bash-completion bugreport. I could be also seen as a feature request. If really needed i suggest open a feature request in a new report.
