The below patch to the Bash man page adds some prose to explain the
recent change to how regular expressions are parsed with the =~
operator. I hope this helps.
One of the lines in the patch is kind of long. I could not figure out
how to break it in a way that did not mess up the appearance of the
resulting man page. If my mailer mangles that long line, I apologize.
--
Francis Litterio
[EMAIL PROTECTED]
--- bash.1.orig 2006-10-03 08:54:26.000000000 -0400
+++ bash.1 2007-03-24 16:06:26.758825600 -0400
@@ -688,6 +688,16 @@
precedence as \fB==\fP and \fB!=\fP.
When it is used, the string to the right of the operator is considered
an extended regular expression and matched accordingly (as in
\fIregex\fP(3)).
+If the regular expression string is quoted with either single or double quotes,
+the special meaning of the regular expression characters (such as
'.', '*', '+', '[', ']', '(', ')',
+etc.) is suppressed. Thus, if the regular expression string contains
+whitespace, it is best to escape the whitespace characters using '\\' instead
+of quoting the entire regular expression string, as follows:
+.if t .sp 0.5
+.if n .sp 1
+ \fB[[\fP "$DATA" \fB=~\fP foo\\ bar.*bletch \fB]]\fP
+.if t .sp 0.5
+.if n .sp 1
The return value is 0 if the string matches
the pattern, and 1 otherwise.
If the regular expression is syntactically incorrect, the conditional
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
