We have 'failglob' in global scope already since filename expansion doesn't really make sense there. Now I think it'd be useful to replace the default behavior in phase function scope. Let's consider the following snippet: for f in *.txt; do ... done Now, we have three possibilities if *.txt doesn't match any files: 1. if things are left as-is, the loop is run with $f == '*.txt'. If we want to figure out whether the glob failed, we need to do something alike [[ $f == '*.txt' && ! -f $f ]] ('*.txt' is a valid filename!). Some cases of missing quoting can result in random expansions depending on the context. 2. If 'nullglob' is enabled, *.txt evaluates to empty list and the loop is not run at all. Some cases of missing quoting will cause silent or unexpected breakages. 3. If 'failglob' is enabled, the ebuild is terminated immediately with error. Therefore, the ebuild author is expected to set what he expected explicitly. Some cases of missing quoting will trigger an explicit error. I don't think (1) really makes sense except when dealing with missing quoting. (2) is expected most of the time and can be easily combined with additional checks for empty results but makes errors from missing quoting quite non-obvious. (3) catches cases of missing quoting nicely but would need to be overrode when dealing with possibly-empty expansions. I'd personally go for defaulting to nullglob in a future EAPI as the most widely useful option. Plus reminding people that '*', '?' and '[' need to be quoted correctly.
(In reply to Michał Górny from comment #0) The argument for introducing this in global scope (see bug 463822) was much stronger than it is for function scope. > 2. If 'nullglob' is enabled, *.txt evaluates to empty list and the loop is > not run at all. Some cases of missing quoting will cause silent or > unexpected breakages. Consider the following example: doinfo foo*.info bar*.info Now if for some reason foo*.info doesn't exist (because upstream has renamed the file, or because makeinfo failed), currently an unexpanded foo*.info will be passed as doinfo's argument and the error will be caught. However, with nullglob the problem would be silently ignored. Even worse occurs for commands like "cat *.txt >foo || die" where nullglob would result in cat reading from stdin instead of failing. > 3. If 'failglob' is enabled, the ebuild is terminated immediately with > error. Therefore, the ebuild author is expected to set what he expected > explicitly. Some cases of missing quoting will trigger an explicit error. See your for-loop example, or the following from elisp-common.eclass: for sf in "${sitelisp}"/site-gentoo.d/[0-9][0-9]*.el; do [[ -r ${sf} ]] && sflist+=("${sf}") done Here the empty expansion is perfectly valid, and at the same time is trivial to catch. How would one handle this with failglob enabled? So I'd rather keep bash default behaviour in function scope.
I agree here and withdraw my proposal.
