On 04/07/2026 07:27, Keith Thompson via Cygwin wrote:
I've reproduced the problem, and it appears to be a change in the
newlib regular expression implementation, for a case that POSIX
leaves undefined.
I have bash 5.3 built from source, which apparently is a bit more
verbose than the default /usr/bin/bash.exe.
Here's a simpler example:
$ [[ x =~ ^(foo|)$ ]] ; echo $?
bash: [[: invalid regular expression `^(foo|)$': empty (sub)expression
2
$ [[ '' =~ ^(foo|)$ ]] ; echo $?
bash: [[: invalid regular expression `^(foo|)$': empty (sub)expression
2
$·
I was also trying to reproduce this but ended up with more questions
than answers, so thanks for identifying and explaining the issue. At
the risk of wandering off-topic...
Firstly, why is =~ completely undocumented in the bash man page? This
question was my first encounter with the feature.
Secondly, why does quoting the expression invalidate it? If the
expression contains white space, how does the parser know where it ends??
$ [[ foo =~ ^foo$ ]] ; echo $?
0
$ [[ foo =~ "^foo$" ]] ; echo $?
1
$ [[ foo =~ '^foo$' ]] ; echo $?
1
Just wondering aloud!
Regards,
Scott
P.S. I found the answers to some of these questions on the '3.2.5.2
Conditional Constructs' part of the 'info' manual horribleness, but
thought I'd post this anyway in case anyone else was in the same boat...
https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#index-_005b_005b
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
