When I run "eselect opengl set 1" the script hangs. The reason is that the function relative_name() in /usr/share/eselect/libs/path-manipulation.bash goes into an endless loop. The variable "c" is always empty and the variable "dir" never changes, thus the loop never terminates. With bash-4.1_p9 everything is fine.
@base-system: Is the following an intended change of bash's behaviour, or is it a bug in bash-4.2? With bash-4.1_p9: $ foo=abcdef $ bar=ab; echo ${foo##"${bar}"cd} ef $ bar=; echo ${foo##"${bar}"abcd} ef With bash-4.2: $ foo=abcdef $ bar=ab; echo ${foo##"${bar}"cd} ef $ bar=; echo ${foo##"${bar}"abcd} abcdef I.e., an empty string in double quotes doesn't match any more within parameter expansion. The following is strange, too: $ echo ${foo##""abcd} abcdef $ echo ${foo##''abcd} ef
i'll have to ask upstream, but it seems to me that double quotes make no sense. there is no word splitting done in the middle of parameters like that which would require double quotes in any way. so while i can pursue the issue upstream, i'd suggest you drop the useless quotes from eselect.
(In reply to comment #2) > so while i can pursue the issue upstream, i'd suggest you drop the useless > quotes from eselect. Sorry, but the quotes are not useless. They prevent globbing: $ foo=abcdef $ bar="a*c" $ echo ${foo##"${bar}"} abcdef $ echo ${foo##${bar}} def If I remove the quotes, the relative_path function will break on filenames containing strange characters like *.
lies ! i didnt think of that thus it must not be true ! clearly the new behavior is wrong. i'll follow up with upstream.
Chet posted a patch that seems to work for me. but cvs.g.o is down so i cant commit it. if you want to verify now, that'd be cool.
(In reply to comment #5) > Chet posted a patch that seems to work for me. but cvs.g.o is down so i cant > commit it. if you want to verify now, that'd be cool. Yes, that patch fixes the original problem.
thanks ... ive added that patch (among others) to cvs now
