Re: Regexp string in := parameter expansion triggers failglob

2019-01-08 Thread Andreas Schwab
On Jan 08 2019, polynomia...@gentoo.org wrote:

> Description:
>   When sourcing a script that contains a variable which performs
>   a := parameter expansion with a regular expression while failglob

At this point it is just a random string, not a regular expression, and
the fact that := is used is irrelevant.

>   shell option is enabled, bash-5.0 emits a "no match: " 

At this point it is a glob pattern, not a regexp.

>   echo ${TESTPATTERN}

If you don't want filename expansion, use quotes.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



Re: Regexp string in := parameter expansion triggers failglob

2019-01-08 Thread Chet Ramey
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: " 
>   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 

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, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/