bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Patch to Bash man page to explain new semantics of quoted regexps for th


From: Fran Litterio
Subject: Patch to Bash man page to explain new semantics of quoted regexps for the =~ operator
Date: Sat, 24 Mar 2007 16:17:08 -0400

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
flitterio@gmail.com


--- 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]