On 1/8/19 8:35 AM, polynomia...@gentoo.org wrote:
> Bash Version: 5.0
> Patch Level: 0
> Release Status: release
>
> Description:
> When sourcing a script that contains a variable which performs
> a := parameter expansion with a regular expression while failglob
> shell option is enabled, bash-5.0 emits a "no match: <regexp>"
> error message.
>
> Repeat-By:
> > cat bash5_testscript.sh
> : ${TESTPATTERN:="\(auto|unit\)\?tests\?"}
> echo ${TESTPATTERN}
>
> > shopt -s failglob
> > source bash5_testscript.sh
> bash: no match: \(auto|unit\)\?tests\?
> bash: no match: \(auto|unit\)\?tests\?
> >
Yes, that's the result of this change from back in April:
pathexp.c
- unquoted_glob_pattern_p: a pattern that contains a backslash can
have it removed by the matching engine (since backslash is special
in pattern matching), so if the pattern contains a backslash, and
does not end in a backslash, we need to return true. Fixes bug
reported by Robert Elz <k...@bmunnari.oz.au>
The idea is that the backslash is special to shell pattern matching, and
the glob matching engine will remove it as part of filename expansion, so
patterns with backslashes are deemed to be subject to filename expansion
and therefore to `failglob'.
The bug report was something like (given the existence of a file named
'ab'):
var='a\b'
printf '<%s>\n' ${var}
what should the following print? Clearly $var expands to 'a\b', and, if
that string is passed to the matching engine unmodified as a pattern, the
backslash will be processed as an escape character and match the `b' in
`ab'.
And should the same thing happen when the file is named 'a?' and the
pattern is 'a\?'?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
