Talk:Regular expression/Archive 1

message: The Manual of Style suggests that strings as strings should appear in italics. This convention doesn't make the current page harder to read, so I have edited some passages with that convention in mind. Some questions remain: how should regular expressions be formatted in this article? They currently appear mostly in double quotes (inch-marks), like this:
#the regular expression "gr(e|a)y" matches grey and gray. 
I think that works well, provided we do not add many expressions that include quotation marks. Alternatives would be to use the same convention as for strings: 
#the regular expression gr(e|a)y matches grey and gray
Alternatives include bold face, not least for readabilityl
#the regular expression gr(e|a)y matches grey and gray
or a fixed width typeface, also for readability and proximity to program code
#the regular expression gr(a|e)y matches grey and gray
A alternative solution to the double quotes would be to always present them in slashes, to make it look like perl
#/gr(a|e)y/ matches grey and gray
Opinions are welcome.
On a related matter, I have replaced the union operator ∪ with the vertical bar even in the formal language theory section. I can count at least four different symbols for this in the literature (including the vertical bar), and suggest we use the vertical bar to keep the connection with programming tools and reduce the number of symbols in this article.
Moreover, the choice of default typeface for the Wikipedia leads to a problem for this page, in that there is no distinction between the lowercase letter “l” and the vertical bar “|”. That makes some of the regexes really hard to read, and could be taken as a point in favour of displaying all regexes in the monospaced typeface. Here is an example of two lower-case Ls separated by a vertical bar: “l|l” in the default typeface, and “l|l” in the default monospace.
:The article is quite hard to read because of the problem of “|”, “l” and “I” all looking somewhat similar. I think the change to a monospaced font for regexps would be a very good idea. I know when I read the first example, it took me a few seconds to realise that it wasn’t a lower case “L” that I was looking at… for a moment I thought it was using some new notation I hadn’t seen before. I suppose my only other comment is that the default choice of monospaced font isn’t itself that great, because of the similarity between “1” and “l”, but for an article on regular expressions, the “|” character is a much more relevant issue. — Ajhoughton 10:50, 2 March 2007 (UTC)
thread_title:  Notation and style 

message: *character classes, with negation: [a-z0-9^4-6] ('all lowercase letters plus the digits 0,1,2,3,7,8, and 9')
request verification: "[^" requests negation; a "^" not following the first "[" is taken literally; so this is all lowercase letters, all digits, and "^"
:Correct. My 'vi' and 'grep' agree with you. I will remove it. --JanHidders
----
In the examples section of the Regular expressions in Formal Language Theory it states that 
(a U b)* is equivalent to (ab*)*
However, the first set contains "b", the second does not.
:Indeed, all non-empty strings in the second set start with "a" which is of course not the case in the first set. Fixed now. --Jan Hidders 12:55, 19 Sep 2003 (UTC)
replies: text: Not sure what planet you're from, but on Earth, /abc|def/ matches abc or def, not abcef and abdef.  I reverted your changes --Randal L. Schwartz 20:57, 14 March 2006 (UTC)
replies: text: This is a case in which mathematical usage and practical usage differ. Turmoil accurately describes mathematical usage. Alternation applies to atoms, so in the absence of a grouping construct the alternation operator applies only to single symbols. However, in practice,  Randal L. Schwartz is right. Every matching engine that I can think of behaves as if a string of atoms were implicitly grouped. That is why you need parentheses around the entire alternation construct even if it isn't in the scope of a quantifier. /(abc|def)/ matches "abc" and "def", but /abc|def/ matches not only "abc" and "def" but also "abcdef", "abcef", and "abcdf" due to the ambiguity of the scope of the alternation operator. (If you don't believe me, try it. I just tested this in Perl, egrep, and Tcl to be sure my memory was correct.) Bill 21:24, 14 March 2006 (UTC)
replies: text:  Try that again with anchors. /abc|def/ matches "abcef" because it matches the abc part.  Print out the value of $& to see the part that is matching. To get a good test, you have to say /^(abc|def)$/ which will demonstrate that the vertical bar is choosing either abc or def, and not just c or d. It's all about relative precedence... if you read the regex description, they describe it very precisely and predictably... the "implicit" sequence operator (two atoms next to each other) binds tighter than the vertical bar. --Randal L. Schwartz 14:36, 15 March 2006 (UTC)
replies: text: I did check it with anchors but misled myself. /^abc|def$/ still matches "abcef" etc., which suggested that my explanation above was correct. The substitution test shows you are right. The reason that /^abc|def$/ matches "abcef" etc. is because it is equivalent to (/^abc)|(def$)/. (Personally, I've always thought that relying on detailed operator precedence was nuts, pace the Numerical Recipes folks, and prefer explicit grouping.) My point about mathematical usage versus application stands, though. The usual assumption in mathematical discussion of regular expressions is that you use explicit grouping and don't assume tight binding in sequences. (Incidentally, in a smallness of the world moment, I realize that I once knew your buddy Rich Cower.) Bill 20:50, 15 March 2006 (UTC)
thread_title:  Error in example? 

message: I'm sorry to say it so but that "skript kiddie" t-shirt regexp states for "Hack the planet" with some haxx0r variations: h@<</h4c</hax/hak, da/tha/de/ttha/tth@, planet/p1anet/pl4n3t/planett/pl4nettt. also any number of spaces between the words I do not understand, though, the /i part. --Tordek 19:34, 3 Sep 2004 (UTC)
thread_title:  T shirt text 

message: Javascripts regex.test () do not match '-' (minus sign) for [-a-z] like, for example, Perl does. Javascript requires that '-' is escaped with [\-a-z]. (Tested in Firefox.)
*The article says: "The '-' character should be literal only if it is the last or the first character within the brackets: [abc-] or [-abc].". 
Suggestion: Note that this does not work in some implementations like Javascript and that '\-' is better (this works in all implementations?) and clearer.
*The article also says: "Since the characters '(', ')', '[', ']', '.', '*', '?', '+', '^' and '$' are used as special symbols they have to be "escaped" somehow if they are meant literally. This is done by preceding them with '\'". 
Suggestion: Mention that '-' should (not must) be escaped as well.
It's a small detail, but it would have helped me a few moments ago. :) --Kricke 14:38, 17 june 2005 (CET).
:I've just tested this in Firefox and IE, and escaping minus is not necessary. Shinobu 03:46, 9 October 2006 (UTC)
replies: text: Shinobu is correct. The claim that "[-a-z]" requires an escape to match a hyphen is nonsense. It's simply not the case in Firefox, IE, Opera, Safari, etc., or according to ECMA-262v3, for that matter. --Monger 02:46, 7 August 2007 (UTC)
thread_title:  Javascript and escaping minus 

message: On my computer (Mac running Safari) the alternation character as seen here is nearly indistinguishable from a lower-case L. (The font is Arial, I believe - if your theme matches mine, see for yourself: | l ) In some examples this makes comprehension difficult - for example, I read the first expression in the line
:For example, "gr(a|e)y" is the same as "gray|grey"
as "gr(ALE)y", and since there's no direct reference to alternation in the explanation of the example, I had to rely on my knowledge of regexps to figure out that the character was an alternation operator.
One solution to this problem would be to use the TeX equivalent of the character. Another would be to put all regular expression examples in code form, as suggested above:
For example, gr(a|e)y is the same as gray|grey
I think the latter (code-style) is preferable, but there may be larger Wikipedia style issues at play. Does anyone have any comments or suggestions? Either way the problem should be resolved. -- —  Adam Conover † 17:23, Jun 20, 2005 (UTC)
:I tried to discuss the issue further up. You correctly point out a big problem with this page. --Arbor 18:31, 20 Jun 2005 (UTC)
thread_title:  Alternation character and text appearance 

message: Currently this topic is confusing at best.  The problem is with the material relating to various programming tools that make use of regular expressions.  Regular expressions are primarily a mathematical concept.  As such, the most pertinent sections are those labeled "In formal language theory" and "Implementations and running times."
Other sections contain data that is inappropriate for the topic regular expressions.  For instance, the "Basic concepts" section discusses the operation "?" which does not exist in regular expressions.  Similarly "Traditional Unix regular expressions" mentions operations dealing with placement in a line of text such as "^" and "$" which also have little to do with regular expressions.
I understand that this is good and useful data in the context of regular expressions in programming and in Unix.  I do not mean to say "This is wrong, we must delete it!"  What I suggest is that there be a topic "Regular Expressions in Programming" and that information be moved there, leaving this topic to focus on the mathematical concept of regular expressions.
:Agreed.  Personally, I see the current article as three different things, mixed together. 
:#the theoretical CS perspective...  eg. DFA's from the perspective of regular expressions.  
:#the practical use as general text-matching tools in compilers, editors, grep, and programming languages.  
:#an enumeration of all the possible libraries, blah blah, that implement regexps.  In my mind, the third should be removed, according to m:When should I link externally.
:In terms of enumerating some of the syntax features and differences of specific practical implementations...  I don't think that should be done on this page.  That's been done elsewhere , but if needed inside the wiki, it should be on a separate article (though it's terribly complicated IMHO, especially with things like less which can link with a variety of libraries, and with many libraries being slight derivatives of others). --Interiot 22:09, 21 September 2005 (UTC)
replies: text: Like that edit for example.  PCRE links with many applications (the PCRE homepage lists 13 notable examples).  We don't need to list them all, especially not on this page.  --Interiot 22:35, 21 September 2005 (UTC)
replies: text:  Object. The topic of this article good enough to make this a featured article at some time. It's a wonderful subject, and it's useful. What I don't see this article becoming is a look-up reference for Perl 5 compatible regular expressions or any other variant. That will never work—look at the pages upon pages in Mastering regular expressions needed to cover these many variants. Wikipedia is not a how-to, and it's certainly not a list of API's. But the central issues of Regular Expressions—how they are defined, how they came about, how they are used and in what contexts, how the algorithms work—that's a great topic for an encyclopedia, not really covered anywhere else in a coherent, readable fashion. We need to de-mystify the TCS section and remove some of the enumeration of syntax differences so that this article can have a cleaner focus on the central concepts. --Arbor 08:24, 22 September 2005 (UTC)
replies: text: Later: Actually, we all seem to more or less agree, don't we? I also want to remove the proliferation of syntaxes, I just don't want to split the article—the practicalities are very important, as long as we don't get bogged down providing detailed syntax comparisons. (The Perl page has its own description of Perl's syntax, and that's exactly how it should be done.) But this page needs to explain ^ and $, and relate them to the formal definition. We need to explain that matching is defined differently in tools and CS (namely, that uvw tool-matches p iff v CS-matches p, or, in other words, w CS-matches p iff ^w$ tool-matches p). I am pretty fond of the explanation of ? and + in the TCS-section, explaining that the formal definition is purposefully parsimonious, but has the same expressive power. Such details are exactly missing from TCS text books and programmers' manuals.  --Arbor 08:34, 22 September 2005 (UTC)

text: I am also in favour of splitting this article. This title should cover only true regular expressions as defined by computer science and mathematics, and contain a link to a seperate article on the software development use of the term, which does not strictly conform to the mathematical notion. By splitting the page we could show the true primitives of regular expressions without being distracted by non-primitives or non-regular constructs. And i disagree with the Arbor regarding Perl Compatible Regular Expressions, which have become more orless the standard syntax for most modern backtracking-nfa regular expression implementations. Indeed the PCRE standard of leftmost-longest matching sematics are more common than the strictly regular longest-token matching semantics, and afaik the former is not emulatable by the latter. Full disclosure: I am and have been working on the Perl regular expression engine for some time. Demerphq 14:37, 19 February 2007 (UTC)
thread_title:  Splitting This Topic 

message: In the section titled "In formal language theory", it says the following:
"Sometimes the complement operator ~ is added; ~R denotes the set of all strings over Σ that are not in R. In that case the resulting operators form a Kleene algebra. "
A complement operator is not required in Kleene algebra. Concatenation, choice, and Kleene star operators suffice. I think the above sentence is misleading.
I also would like to question the comment:
"The complement operator is redundant: it can always be expressed by only using the other operators."
Is this so? I have never seen a definition like this. It is generally defined as something like ~A = Σ - A , where '-' represent set minus. However, set minus is not part of the regular expression syntax, so it means the complement operator is "primitive". Or is there something I am missing?
tim 13:54, 25 January 2006 (UTC)
replies: text: Your first comment is correct. Fix it. As to complementation, the easiest way to see that goes via DFA: switch the accepting and rejecting states: hey presto! Instant DFA for the complement. Arbor 14:02, 25 January 2006 (UTC)
replies: text:  Thanks for you (very fast!) response. The change has been made. I see what you mean about the complement operator. I had misunderstood and thought that it was saying that the complement operator could be defined in terms of other operators, rather than expressions containing complement operators could be rewritten to not use them. tim 14:31, 25 January 2006 (UTC)
thread_title:  Complement operators and Kleene algebras 

message: Hello,
I want to negate a whole line starting from a specific caracter, eg.:
"The text to be negated starts here: negated text"
I want to negate all the line starting from the two dots ":".
Is there a way to do this?
Thanks,
Ian Liu.
:You cannot complement anything other than character sets, because this would make the efficient generation of NFAs from regexps infeasible. It's conceivably possible to complement the entire regexp by complementing the final DFA generated from the NFA (for systems that generate such a DFA), but this isn't usually very useful. Deco 00:29, 27 January 2006 (UTC)
thread_title:  How to negate a whole line? 

message: Greetings,
What a difference a space character can make...
The section title "In formal language theory" puzzles me.  Does it mean:
  In that discipline we call formal language theory
or does it mean:
  Here's some informal language theory
If the former, please lose the initial "In" and just call it "Formal Language Theory".  If the latter, please lose the space between "In" and "formal" to make the title "Informal language theory".
In the case of the former, I don't mind using a preposition as the first word, but using "in" in this case is a little too close to the word "informal".
Thanks,
David
:Hi David. Why not fix it yourself? WP:BOLD Welcome to Wikipedia! Arbor 08:15, 4 March 2006 (UTC)
replies: text:  Hmm, I don't think being bold is the problem here. Anyway, the edit history  shows it comes from a heading "Regular Expressions in Formal Language Theory", so I'll remove the "In". Thanks for picking that out, it's good to know where there's confusion. --H2g2bob 03:07, 24 June 2006 (UTC)
thread_title:  "In formal language theory" or "Informal language theory"? 

message: "Sometimes the complement operator ~ is added; ~R denotes the set of all strings over Σ that are not in R. The complement operator is redundant: it can always be expressed by only using the other operators."
:How? --Ihope127 02:31, 24 June 2006 (UTC)
replies: text: It's true, but completely non-obvious. First, you translate the regexp to an NFA. Then, translate the NFA to a DFA using the powerset construction. Then, complement the set of final states. Then, translate back to a regexp. The resulting regexp will recognize the complement language, but may be an exponentially larger string. Deco 17:38, 26 June 2006 (UTC)
thread_title:  This doesn't seem right 

message: Many text editors have a "search and replace" that allows regexes in the "search" part.
This article emphasizes "searching", but only hints at the possibility of using regexes in the "replace" part.
For example, "\0" represents the entire thing matched, "\1", "\2", "\3", etc. represent various parts of the thing matched.
If the string I type in the "replace" part -- for example,
  \0
(intended to add literal "" and "" around what the regex found, whatever it may be) 
is not technically a regex, then what is it called?
If this is not the appropriate encyclopedia article to discuss the "replace" part, which encyclopedia article is?
--70.189.73.224 15:35, 17 September 2006 (UTC)
thread_title:  search and replace 

message: Google Analytis uses RegEx now and so the need to understand them is greater than before. But, all the examples here are tech-heavy Perl (or as one guy said on the Web Analytics forum, "To me, Perl is something that comes in an oyster." And that was someone who was writing his own RSS application...) Anyway, we need examples that are more relevant to that market.
Rsteif 22:09, 23 September 2006 (UTC)
thread_title:  Google Analytics and RegEx 

message: Someone in the past removed a bunch of link - here is the whole list from that awful day, so people can re-add the ones they find useful. -- Wriggleybum 08:27, 30 September 2006 (UTC)
replies: text: That was me; I announced it here as well, see above. By the way, most WP editors should be able to use the "history" tab to find and bring back whatever they find necessary, so in general there is no need to "resurrect" material by copying it to the talk page. Arbor 09:15, 30 September 2006 (UTC)

text: A good way to point to an edit that you find problematic is to include a link to the diff, like this: . That shows what I removed and when, including my edit summary. Having done that, I will remove the section of links you added to this talk page. Arbor 09:18, 30 September 2006 (UTC)
replies: text: Much appreciated. I've been trying to keep it sparse. For anyone who thinks this is a bad idea, please review WP:NOT. -Harmil 19:06, 2 October 2006 (UTC)
replies: text: Very Bad Idea. Don't have to think it. A link to site that was up for barely 24 hours generated a very large volume of traffic from this article. Strongly suggests this page is failing to provide answers for people coming here. WP NOT, is fine and good, but I believe you'll also find that WP is not about useless information for no purpose. Earnestly suggest you reconsider your pruning efforts or do a better job in the article. dmoz is also fine and good, but why are you making it hard for people? --Gavferr 04:14, 14 October 2006 (UTC)
replies: text: More likely it was the multitude of editors who watchlist this article following the link for validation.  — EncMstr 04:24, 14 October 2006 (UTC)

text: Gavferr, based on your comments, I take it that you are the maintainer of one of the sites that had been linked to from this article? If so, please do review WP:NOT, and if you decide that you have a justification for a particular external link, let us know. "a link ... generated a very large volume of traffic," doesn't actually address the concern. -Harmil 04:26, 14 October 2006 (UTC)
replies: text: Personally I could care less if you link or don't. I derive zero benefit either way. Do keep in mind that those links keep growing. Ask yourselves why? People aren't finding what they want here, they find it somewhere else, and try and help by putting a link up. Then think of what fraction of people who would even *bother* doing the editing. QED. You can either learn from this or not. It's your call as the keepers of the page, not mine. The goal of WP is not to freeze articles in stasis but improve them. This one is frozen and has plenty of proof that it is failing. I care enough about WP succeeding to try and help by alerting you to the issue, but not enough to waste time arguing with pedants. Apologies if the truth offends. --Gavferr 09:04, 15 October 2006 (UTC)

text: The problem with that sort of logic is that it's an excellent reason to keep a link on a Web directory service, which Wikipedia is not. Links in an article should further inform the reader, and allow them to perform further research on their own. If there's a link that you think regular expression users should know about, I suggest strongly that you submit it at DMOZ. -Harmil 06:11, 6 October 2006 (UTC)
thread_title:  External links that were removed en-masse 

message: Why is Javascript not mentioned in the article? I think to most users it is a much more familiar and accessible example of a language supporting regexen than the relatively speaking more obscure tcl. Shinobu 03:49, 9 October 2006 (UTC)
thread_title:  Javascript? 

message: I have no idea what McCullough and Pitts have to do with regular expressions. I am removing the statement making that reference. If someone can dig up a reference that McCullough and Pitts had anything to do with the early history of regular expressions or finite-state languages, feel free to revert. Pexatus 01:06, 21 October 2006 (UTC)
thread_title:  McCullough and Pitts 

message: A new section entitled "Regular Expressions Example (Visual Basic .NET)" does not seem at all appropriate to me, as the example does not seem at all useful, and is more about visual basic than regular expressions. It also contains misleading statements, such as "Regular Expressions have been fully integrated into Visual Studio", I think it means integrated into the .NET framework, and "In particular, Visual Basic .NET", what bout c# etc. where regex implementation is pretty much identical. Martin 09:05, 23 October 2006 (UTC)
replies: text: I agree with all that. Removed the section, and scattered the text into #Regular expression and the .NET framework and #Uses of regular expressions. Both could do with more work though. --h2g2bob 11:48, 23 October 2006 (UTC)
replies: text:  I've added an  tag to the .net section. I have no knowledge of "lookaround", which looks to be a key concept in .net regexps. Plus, I have no particular desire to find out. --h2g2bob 12:15, 23 October 2006 (UTC)
replies: text:  "lookaround" is jargon for "positive/negative lookahead/behind assertion" --Demerphq 15:59, 23 December 2006 (UTC)
thread_title:  "Regular Expressions Example (Visual Basic .NET)" 

message: Someone added searchmonkey to the "See also" section. This makes about as much sense as adding Ford F-100 to Fuel injection "See also" section. It certainly makes sense to disucss (in prose, with as much context as possible) any product which has made notable contributions to the real-world use of regular expressions, but the "See also" section isn't the place to do that. That section should be reserved for directly related or very similar topics that are not otherwise covered in the body of the article. -Harmil 21:25, 9 February 2007 (UTC)
thread_title:  searchmonkey 

message: Speaking as a reader of this article I was quickly baffled in the very first section by the following:
"The asterisk indicates there are 0, 1 or any number of the previous expression. For example, "go*gle" matches ggle, gogle, google, gooogle, etc."
I had to do a double take because I was under the impression that the asterisk was used as a wildcard in regular expressions.  Some quick googling led me to discover that I was mistaken.  Through my googling though I quickly came to the conclusion that this mistaken impression is probably very common.   Perhaps a section talking about common misconceptions like this might be in order? —The preceding unsigned comment was added by 64.126.82.205 (talk) 08:11, 14 February 2007 (UTC)
replies: text: The * as a wildcard is non-Unix, it was DOS (maybe CP/M that was before my time). — RevRagnarok Talk Contrib 11:48, 14 February 2007 (UTC)

text: I don't know about CP/M, but the DOS implementation was flawed.  The asterisk could only appear at the end of a field.  That is, FILE*.* worked as expected, however *FILE.C would be interpreted as *.C.  It seems the asterisk was expanded into the single-character wild card ? to fill out the field.  As these were 8.3 filenames, FILE*.* was transformed into FILE????.??? while *FILE.C became ????????.C for matching purposes.  —EncMstr 16:20, 14 February 2007 (UTC)
replies: text: * wildcarding is very old, but Unix, DOS, VMS and various other systems supported this kind of wildcarding. Wildcarding is a subset of the capability of regular expressions, but is not directly related. The clarification should probably be made if it's not already between the two. Modern Unix wildcarding is VERY sophisticated, but the fundamental difference is that wildcarding expresses missing segments, where regular expressions express sequences. Thus .* in a regular expression is functionally equivalent to * in a wildcard, but you don't have to describe what it is that comes between in a wildcard (and cannot). Alternations are sometimes possible with {a,b,c} in wildcards, but not everything supports this, and it's limited in its capabilities (e.g. you cannot specifiy the repetition of an alternation, as you can with (a|b|c)*). -Harmil 17:49, 14 February 2007 (UTC)
thread_title:  Perhaps a section on clarifying the asterisk is in order? 

message: This section reads like a textbook.  Further, it seems like it could be condensed quite a bit to make it more relevant to regular expressions (formal language theory does have its own article, after all). -- Super Aardvark 01:09, 31 March 2007 (UTC)
thread_title:  Tone of the Formal Language Theory section 

message: The section "Uses of regular expressions" is not very useful and feel out of place. Regexes has many uses other than syntax highlighting. Let's just link to Regular expression examples instead. --Apoc2400 06:10, 2 April 2007 (UTC)
thread_title:  Suggest removing section "Uses of regular expressions" 

message: Can someone provide a formal definition for regular expression?
--CBKAtTopsails 03:12, 8 June 2007 (UTC)
thread_title:  Missing The Formal Definition 

message: I added the following rules on [...]: []...] matches ] and the rule on placement of - to match a -. I also fixed the regexp for [:punct:], which had ] in the wrong place. - PGSONIC 17:09, 31 July 2007 (UTC)
replies: text: The rules regarding "]" as the first character in a character class is flavor/engine specific. For example, Internet Explorer agrees with you, while Firefox does not. --Monger 01:18, 15 August 2007 (UTC)
thread_title:  Rules on [...] 

message: FYI, Google does offer regex search, at least on their codesearch. (google.com/codesearch) 
That might have to be changed 129.92.250.39 21:00, 6 August 2007 (UTC)
thread_title:  Google and regex search 

message: In the example "((great )*grand )?(fa|mo)ther", it should be "((great )*grand)?(fa|mo)ther" since in English (US/UK) grandmother and grandfather is one word, not two.
:That is true. Be bold and fix it. Dcoetzee 22:47, 14 August 2007 (UTC)
thread_title:  Me being a pedant 

message: There are two references in the article to "multiline mode", but no definition or any other information.  Being a beginner at regexp, I know there are parameters that can change the "mode", but not enough to explain it.  Could this be added to the article?  Thanks! -- SatyrTN (talk | contribs) 01:40, 16 August 2007 (UTC)
thread_title:  "Multi line mode" 

message: I'm concerned that the "example of regular expression syntax" in the introduction uses a feature, \b, which is a Perl extension not found in many common regular expression engines, and hardly representative of common regex syntax at all.  I'd replace it with a *-based example if I could think of a good one... -- 81.86.133.45
: First of all, "common regex syntax" these days is Perl-derivative. I'm not crazy about the \b-based example, but I think it is better than a *-based example because it is a simple to understand case of something useful which cannot be done with more familiar wildcards. In any case, the word boundary concept has been around with regular expressions since before Perl (via the < and > metacharacters found in a number of traditional Unix tools).  --Monger 23:57, 12 November 2007 (UTC)
replies: text: I think zero-width assertions should be avoided in any introductory pattern, because they're less intuitive than positive width patterns. Far better to use something based on * and |. As for being something cannot be done with more familiar wildcards, why bother? More familiar wildcards are ultimately derived from regular expressions and are relevant in the context. Dcoetzee 05:49, 12 December 2007 (UTC)
replies: text:  Sez who? The claim that [all] zero-width assertions are less intuitive is obviously subjective. --Monger (talk) 07:52, 12 December 2007 (UTC)
replies: text: My own opinion. Just try to answer the question "what is it matching?" It's complicated. It deserves to be postponed. Just look at a typical Perl manual or book - they usually reserve a later section to expound upon these. Dcoetzee 02:32, 13 December 2007 (UTC)
replies: text:  The question is of course quite simple to answer. It matches successfully at the position between a word character and a non-word  character, according to the regex flavor's definition of these terms (e.g. a Unicode-based interpretation might be used, and a very small number of flavors do not base \b and \w on the same definitions). The reader does not need to understand all the subtleties of what matching an empty string means or the variations on precisely which characters are considered word characters by every regex flavor in order for the functionality to be reasonably straightforward and intuitive. Also note that the use of * and | (your preferred example tokens) can also involve the concept of elision, which is really the most complicated aspect of any zero-width assertion. --Monger (talk) 17:17, 27 December 2007 (UTC)
thread_title:  \b example in introduction?! 

message: This article shows up in a Google search result for regular-expressions as:
"Regular expression - Wikipedia, the free encyclopedia
"A Wikipedia articele on regular expressions with an informal discussion, a formal definition and examples."
Note the word "articele". Where does it come from? I can't find it on this page and don't know how to correct it.
Not overly important, but we want to be perfect, don't we? (:-)
Hgmichna (talk) 12:18, 4 January 2008 (UTC)
thread_title:  Typo in Google find 

message: Once more, I'm going to restore the wording that uses "text" instead of "string".  I haven't heard anyone making a strong defense of "string", and perhaps the recent change was inadvertently included with other changes.   
At this time I will not remove the "abbreviations" part from the first sentence, but I still object to it. 
One editor invoked wp:mos as supporting placement at the first.  In this case, I don't think it does.   One part of mos says "The use of abbreviations should be avoided when they would be confusing to the reader, interrupt the flow, or appear informal or lazy."  I think that the usage here qualifies as "interrupts the flow" and "appears informal". If it was just one abbreviation, it would be OK, but now five are listed in a parenthetical phrase that is 11 words long, which certainly interrupts the flow.  They are also not true abbreviations - they are slang. Leotohill (talk) 18:56, 18 January 2008 (UTC)
thread_title:  That opening sentence, again. 

message: BRE and ERE should probably have redirects to this page. Speaking for myself, I typed BRE in the wikipedia search box and was surprised to get a disambiguation page which didn't mention Basic Regular Expressions and typed in ERE and was even more surprised to just get most likely search results (which didn't include this page). No big deal, either way, though.  —Preceding unsigned comment added by 68.214.235.119 (talk) 03:08, 12 February 2008 (UTC)
replies: text: Added Basic Regular Expression to BRE disambiguation page, and created ERE redirect to this page.  MeekMark (talk) 12:32, 29 February 2008 (UTC)
thread_title:  redirects 

message: This link damages the topic by pointing to a poorly organized set of blog-style entries of trivial scripts lacking tutorial content.  The site as a whole is as noted by another editor poorly responsive (perhaps from the way the scripts are added in a haphazard manner).  The IP-editor(s) intend to use Wikipedia for promoting their site rather than improving the Wikipedia topic. Tedickey (talk) 12:02, 29 February 2008 (UTC)
thread_title:  sexyregex.com 

message: POSIX Character Clasess [\x00-\x1F\x7F] is not working. I had to use [:cntrl:] in order to make it work properly. All others are working just find. Unfortunately I don't have the solution or the proper expression but I am just leaving a feedback for anyone else who can find out what is wrong with it.
This was the expression not working. Note that I am not using ending line "$".
^[\x00-\x1F\x7F]+
This is the corrected expression which is a workaround and not a full solution.
^[:cntrl:]+
Erick V...
03/31/08 13:36 EST.  —Preceding unsigned comment added by Pele matosky (talk • contribs) 17:43, 31 March 2008 (UTC)
thread_title:  POSIX Character Classes [\x00-\x1F\x7F] is not working. 

message: Says Regular expression#POSIX Basic Regular Expressions:
: ". Matches any single character except newlines"
Says the spec:
: "In the regular expression processing described in this specification, the newline character is regarded as an ordinary character and both a period and a non-matching list can match one."
: "A period (.), when used outside a bracket expression, is a BRE that matches any character in the supported character set except NUL."
I changed the article accordingly and added a note: "many varieties exclude newlines". --TuukkaH (talk) 14:54, 12 April 2008 (UTC)
thread_title:  . and newline characters 

message: Sorry, I should probably figure out how to edit the article myself but a peek at the "how to add a citation" seemed a little overwhelming (I have never edited a wikipedia article)...  So below is a citation for the "citation needed"  in the following article text:
("grep" is a word derived from the command for regular expression searching in the ed editor: g/re/p where re stands for regular expression[citation needed])
Perhaps some kind sole could add the following reference?
Article "Statistical Text Processing", by Kernighan, Lesk, Ossanna, 
in "The Bell System Technical Journal", Vol 57, No. 6, Part 2, 
July-August 1978. pg 2140:
"...the etymology of the name is from the editor command g/r.e./p where r.e. stands for regular expression."  —Preceding unsigned comment added by 64.24.133.241 (talk) 02:02, 6 July 2008 (UTC)
thread_title:  grep citation 

message: \( \) 	
\{m,n\}  —Preceding unsigned comment added by Jamie Kitson (talk • contribs) 22:37, 6 August 2008 (UTC)
replies: text: Other than the obvious (to distinguish those characters from the unescaped literal ones)? Tedickey (talk) 22:52, 6 August 2008 (UTC)
replies: text: Some flavors of regular expressions prefer to use brackets as metacharachters and the escaped equivalents as literals.  Others prefer the opposite.  For example, the regular expressions used in the search command of Vim require a backslash escape in front of nearly everything.  For example, the Vim regular expression /abc\|\(123\)\{2\}/ is equivalent to the Perl regular expression /abc|(123){2}/.  In fact, Vim regexes are basically Perl regexes with different rules about what need backslashes.  Karl Dickman talk 20:48, 23 September 2008 (UTC)

text: The backslashes are used (see the source for BRE's, which is the context in which you made your changes. Tedickey (talk) 11:35, 22 October 2008 (UTC)
thread_title:  Why The Slashes? 

message: should "implements the various improvements introduced by Perl" be "implements the various extensions introduced by Perl" 81.138.55.194 (talk) 10:47, 11 August 2008 (UTC)
thread_title:  Bias? 

message: Should the history contain dates? 81.138.55.194 (talk) 10:47, 11 August 2008 (UTC)
replies: text: Probably (along with reliable sources - which the history already lacks) Tedickey (talk) 13:33, 11 August 2008 (UTC)
thread_title:  History 

message: can someone post a link to where i can read more about the algorithm that proves equality of regular expressions?  —Preceding unsigned comment added by 84.75.161.109 (talk) 15:29, 13 August 2008 (UTC)
replies: text: The procedure is fairly standard: Starting with two regular expressions r_1 and r_2, you first convert each to an equivalent nondeterministic finite automaton A_1 and A_2, respectively. Then apply the powerset construction to A_1 and A_2 each. The resulting deterministic finite automata can be tested for equivalence by minimizing them first and then testing whether the results are isomporphic, that means, are equal up to renaming of states. Details can be found in virtually any textbook on automata theory, see for example Chapter 3 in Introduction to Automata Theory, Languages, and Computation. Two notes: First, the above applies only to regular expressions in the "formal language theory sense", and not to (say) perl regexes. Second, in the worst case the subset construction takes exponential time and space (although you may well be lucky and the worst case does not occur in your examples). HTH. Hermel (talk) 10:03, 9 April 2009 (UTC)
replies: text: The chapter you mention shows the algorithm for converting regexs into NFA, and the algorithms for converting NFA to DFA and minimization are of course well known. However, I fail to find in that book the description of how to test whether the resulting graphs are isomorphic.  —Preceding unsigned comment added by 84.226.131.226 (talk) 18:59, 7 October 2009 (UTC)
thread_title:  'equal' regexs 

message: How about lookahead & lookbehind feature?  --Octra Bond (talk) 10:58, 26 February 2009 (UTC)
thread_title:  Lookahead & lookbehind 

message: Discussion on the Regular expression examples  article suggests merging that content into this article.  Seems a good idea to me Chas49 (talk) 12:35, 31 March 2009 (UTC)
replies: text: Given the quality concerns already noted on that page, it's not really a "good idea" Tedickey (talk) 18:00, 31 March 2009 (UTC)
thread_title:  Merge content from [[Regular expression examples ]] 

message: NFA-style algorithms can extract subexpressions and do lazy quantification.  They can do approximate matching, too, and theoretically lookahead/behind (though I haven't seen it implemented).  LibTRE does all these things, has been out for a while, and probably should be cited.  They can't do backtracking, though.  —Preceding unsigned comment added by 171.66.53.79 (talk) 22:58, 1 April 2009 (UTC)
thread_title:  NFA-style algorithms 

message: Shouldn't this article be in the Theory of Computation category? angelofwisdom (talk) 23:44, 12 July 2009 (UTC)
replies: text: Yes, indeed. Done. Hermel (talk) 21:23, 26 September 2009 (UTC)
thread_title:  Theory of computation 

message: I don't think that this is supported.  See re_comp and regcmp.  It also demonstrably doesn't work with the regexec on my Linux system. --Dustin (talk) 23:32, 15 April 2010 (UTC)
replies: text: Ah, better evidence is here.  I'll just change this --Dustin (talk) 23:38, 15 April 2010 (UTC)
thread_title:  Backslash-escaping hyphen in [..] in BRE and ERE 

message: There ought to be a short discussion of human factors involving the use of regular expressions. Although they are compact and highly expressive, when they are more than trivially complex they become extremely difficult to decipher even for “wizards”. They’re often derided as a type of write-only language, partly because they seem to be easier to write than to read.  I’m unaware if there have been any studies done on this issue, but there at least are plenty of anecdotes out there that could be cited. The famous example is Zawinski’s saying: “Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.”. I’d write the section but I’m no regexp expert. — 128.171.68.145 (talk) 20:22, 3 June 2010 (UTC)
replies: text: Jamie's not a bona fide expert in this area either.  Skipping the random quotes and focusing on research results would be a good way to go. Tedickey (talk) 20:41, 3 June 2010 (UTC)
thread_title:  Human factors 

message: What does "regular expression engines built directly into their syntax" mean anyway?  Zarboublian (talk) 07:52, 15 September 2010 (UTC)
replies: text: Presumably it means that patterns don't have to be parameters to a function call, e.g., as awk does, and that the regular expressions are handled within the interpreter rather than in a separate program. TEDickey (talk) 09:14, 15 September 2010 (UTC)
replies: text: But an "engine" is an implementation concept and can't be part of the syntax. Zarboublian (talk) 08:08, 16 September 2010 (UTC)
replies: text: Your "implementation concept" is however common usage for whatever implements a regular expression TEDickey (talk) 20:30, 16 September 2010 (UTC)
replies: text: That's what I said -- and syntax is a thing that is implemented, not a part of the implementation.  So is there a reliable source that makes this comment in these terms?  Zarboublian (talk) 11:30, 18 September 2010 (UTC)
replies: text: lots of places to look at TEDickey (talk) 22:00, 18 September 2010 (UTC)
replies: text: Then you won't find it hard to exhibit one.  Zarboublian (talk) 07:55, 22 September 2010 (UTC)
thread_title:  Engines built-in 

message: I think this page should look more like a tutorial and less like an abstract treatise. Most of the viewers on this page will be newbies looking for simple examples.  —Preceding unsigned comment added by 89.150.116.86 (talk) 13:08, 14 May 2010 (UTC)
replies: text: Definitely not. Wikibooks is a better place for your idea. If you think something needs additional explanation by example, please ask for it. Reducing the the current quality, however, is not a good suggestion.  --Zahnradzacken (talk) 16:11, 14 May 2010 (UTC)
replies: text: OK with Zahnradzacken. And it is already there at Wikibooks: Regular Expressions/Examples. So anyone has an obligation to let Regular expression examples in the See also section of Regular expression point to that Wikibooks article and delete the Regular expression examples Wikipedia article here? --Pypes (talk) 14:47, 15 October 2010 (UTC)
thread_title:  More examples, less theory