Bugzilla – Bug 148251
strange unalias problem with bash
Last modified: 2006-02-08 10:04:10 UTC
I just noticed a strange problem with bash. It happens, that I use a /etc/profile.local for many years, containing among other things: alias which='type -p' It's enough to create a /etc/profile.local just containing that one line to trigger this problem. With 10.1 Beta 3, it throws and error in /etc/bash.bashrc: -bash: /etc/bash.bashrc: line 210: syntax error near unexpected token `(' -bash: /etc/bash.bashrc: line 210: ` which () {' immediately preceded with: unalias which 2>/dev/null Looks to me like unalias doesn't work as expected.
Reproducable here. # su - -bash: /etc/bash.bashrc: line 210: syntax error near unexpected token `(' -bash: /etc/bash.bashrc: line 210: ` which () {' -bash-3.1# alias alias which='type -p' <--- unalias didn't work. I did some tests - it seems that the alias command also doesn't work inside /etc/bash.bashrc. I added an additonal alias command: unalias which 2>/dev/null alias which='/usr/bin/which' <--- added which () { After logging in, I still see the error message - and which is still aliased to 'type -p'... Possible solution: use /usr/bin/which () { (instead of calling "which () {" without a pathname). This works on my system.
Please try this --- /etc/bash.bashrc +++ /etc/bash.bashrc 2006-02-06 11:04:39.000000000 +0000 @@ -207,7 +207,7 @@ alias rd=rmdir alias md='mkdir -p' unalias which 2>/dev/null - which () { + function which () { local file=$(type -p ${1+"$@"} 2>/dev/null) if test -n "$file" -a -x "$file"; then echo "$file"
Works - no more error messages :-) Thanks!
Same here ;-) The question is, does this parsing problem may bite us somewhere else later with probably more fatal effects?
Hmmm ... the specs are not clear at this point of matter. You can define a shell function with or without the keyword `function', but if you skip this keyword the parentheses `()' are not optional anymore. As long as the other shell functions will not used as an alias all should go well.
It seems to be a gereral bash problem - I just tested in a xterm on 10.0: - if an alias is set, you can't define a function without the "function" keyword prepended - even if you define a function with "function foo () {...}", it won't be used as long as the alias is set This also means that the function "which" you defined will not be used if an alias "which" exists. I still wonder why unalias doesn't work in bash.bashrc :-/
If an alias is set it should win over every shell function or shell builtin or program found in the execution path. So far this is OK. If a name is used for an alias you can not use this name afterwards for an function without the keywoard `function' ... IMHO this is also OK. The remaining problem is why the unalias in /etc/bash.bashrc doesn't work for 100% which is to unset the alias but alos to free the reserved name.