Bash 5.1 seems to have introduced stricter quoting/word expansion rules. At least in the cases I checked, it seems valid and the original use was wrong. In any case, it's stricter now.
Bash 5.1 is now stable. Ionen has gone looking for other possible cases but hasn't found any. Posting this so that people see it and have it in mind if they hit any odd issues.
From a QA standpoint, there are issues that remain, albeit ones that might rarely be observed in practice. Consider the following. qgrep -x '^[[:space:]]*\$\(.*\$\{' Of these results, let's consider the matches made against the openssh ebuild as an example. $(use_with kerberos kerberos5 "${EPREFIX}"/usr) $(use_with ldns ldns "${EPREFIX}"/usr) Here, we can see that EPREFIX is being correctly quoted in the course of being specified as an argument to use_with, which is the proper. However, the command substitution that conveys the string printed by use_with is not quoted, which is improper. Therefore, if the value of EPREFIX were, say, "/foo bar", with USE=kerberos in effect, the composition would be such that two words are incorporated by the myconf array:- declare -a myconf=([0]="--with-kerberos5=/foo" [1]="bar/usr") But it should really be composed as a single word. Through double quoting the command substitution, the composition becomes as it ought to be. declare -a myconf=([0]="--with-kerberos5=/foo bar/usr") Now, one might be inclined to dismiss such by stating that the value of EPREFIX never matters in practice, that the fragility of Makefiles and build systems in general might otherwise thwart the intent etc. Nevertheless, the point stands that the code is improper. As Dijkstra once said, program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. Besides which, it's possible that there are more tangible instances of this defect lurking in the tree. I have not performed an audit, mainly because I am uncertain as to whether there would be any collective interest in working on this as a QA principle. In any case, I do think that it would be beneficial for ebuild authors to be a little more rigorous. Generally, authors appear to understand where - and why - variables must be quoted, but this appears to be less true of command substitutions. Commonly, word splitting and pathname expansion as a side effect is something to be avoided. So, just as with variables, a sensible rule of thumb would be to always double quote them, should there be the slightest doubt.
