Page 2 - So What's A $#!%% Regular Expression, Anyway?!

I have another question related to this part of the article.

The text says:
"and zero or one occurrence of the preceding character"

And /Wil?/ would match "William" ?

Howcome? There are two occurences of the 'l'
in William.

-- Martin

You guys are good! In fact, why, maybe you guys are........... Enlightened?

The hook phrase in this article for me, *has* to be....

"- kinda like Madonna, their popularity cuts across languages and territorial boundaries.."

Truly marvellous to find a chuckle appear in the throat, while reading a serious and informative tech. article..... please, Gurus, KEEP IT UP!

A.

Searching around CPAN modules, I found this one that could be interesting for you :-)

Email-Valid seems to test e-mail and server also.

http://cpan.valueclick.com/authors/id/MAURICE/

nice work guys. keep it up. loved reading every bit of it. even though i am a hardcore unix guy, even i picked up a few points from ur article.
<br>
<br>
looking out for more of your articles.
<br>
girish

/Wil?/ will match the "Wil" portion of "William", not the whole word. -- Greg

is there a java script that can open a application on your computer like word or excell.

This is top-notch material, and I'd like to get it in a form where I can really study it. Is it available as a Word document?

For someone who doesn't want to bother with RFC 822 checking, I use this little regex to check for RFC 821 compliance (which is what I care about) after stripping away any enclosing '<>' angle brackets and any leadning/trailing whitespace. I want submitted email addresses to match RFC 821 (for the local part, the part before the '@' at symbol, anyway) and I also do minimal sanity checking on the domain portion.

Here's the beastie I use (there are no guarantees it is bug free, and if a new non-two-letter TLD is added in the future, this regex will have to be updated):


<!-- Code -->
<p><pre><font color=#008000><xmp>
#!/usr/bin/perl

while(<>) {
# Strip newlines, leading/trailing whitespeace:
s/[\r\n]+$//;
s/^\s+//;
s/\s+$//;
# Strip any enclosing angle brackets:
while (s/^<\s*(.*)\s*>$/$1/) {};
if (!/^("([\x00-\x09\x0b-\x0c\x0e-\x21\x23-\x5b\x5d-\x7f]|\\[\x0-\x7f])+"|([\!\#\$\%\&\'\*\+\-\/0-9\=\?A-Z\^\_\`a-z\{\|\}\~\.]|\\[\x0-\x7f])+)\@(([a-z][a-z0-9-]{0,62}\.){1,62}(com|net|org|edu|gov|mil|int|[a-z]{2})\.?|\[?(\d{1,3}\.){3}\d{1,3}\]?)$/i || ($email =~ /\@\[?(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})\]?$/ && ($1 > 255 || $2 > 255 || $3 > 255 || $4 > 255))) {
print "INVALID ADDRESS: $_\n";
} else {
print "VALID ADDRESS: $_\n";
}
}
</xmp></font></pre><p>
<!-- Code -->

question:

When I use grep, can I ask for string 1 OR string 2?

You have to use egrep

eg

egrep '(foo|bar)' file

the quotes are important so that the shell doesn't interpret the |

REs were a key/seminal element of work in the mid-70s on compilers (the real work on higher level language; Assembler and Fortran just weren't enough); specifically, the lexical analyzer generator for a compiler compiler (generator). Work in things like "Bakus-Naur form" notation (nomenclature) alluded to their use for the sake of brevity and completeness in on-paper specifications (you had been required to write out a "proof" you should be allowed to run a program on "the computer"), and hence they were incorportated as pivotal elements in "lex" and "yacc" and their progeny (it's what "lexing" does/is). Sources of documentation, and especially history, on "lex" and it's progeny may be "the" place to find bibliographic citations to support my premise that ALL the work on REs was done (finite state analysis; completeness) in the mid-to late 70s, and has long since been set aside in favor of "incomplete" bogus "new" analysis.

Consider taking a little time to find the legitimate original work, for the sake of it's provable completeness, if not in pursuit of your own provable completeness.

Keep an "eye out" for names like Aho and Johnson; the "other guys" at Bell Labs that caused "working in Unix" to be the much favord alternative (of then/for-all-time) that may be responsible for it's "real" success. Their bibliographies will reveal "who created these !@#$ REs", anyway, and why?

Regards,

Jim Cunningham

P.S.

If you get reasonably good at them, try lex instead of sed and such, on any "really huge" data collections, for speed, bc. that's where sed learned to do what it does.

"lex"'s output "table" is meant to be "passed" to a "next/higher" filter, and as such, makes analysis decisions and prioritizing more clear (weighted) and yes, trivial, toward attaining whatever goal the data analysis seeks.

REs were a key/seminal element of work in the mid-70s on compilers (the real work on higher level language; Assembler and Fortran just weren't enough); specifically, the lexical analyzer generator for a compiler compiler (generator). Work in things like "Bakus-Naur form" notation (nomenclature) alluded to their use for the sake of brevity and completeness in on-paper specifications (you had been required to write out a "proof" you should be allowed to run a program on "the computer"), and hence they were incorportated as pivotal elements in "lex" and "yacc" and their progeny (it's what "lexing" does/is). Sources of documentation, and especially history, on "lex" and it's progeny may be "the" place to find bibliographic citations to support my premise that ALL the work on REs was done (finite state analysis; completeness) in the mid-to late 70s, and has long since been set aside in favor of "incomplete" bogus "new" analysis.

Consider taking a little time to find the legitimate original work, for the sake of it's provable completeness, if not in pursuit of your own provable completeness.

Keep an "eye out" for names like Aho and Johnson; the "other guys" at Bell Labs that caused "working in Unix" to be the much favord alternative (of then/for-all-time) that may be responsible for it's "real" success. Their bibliographies will reveal "who created these !@#$ REs", anyway, and why?

Regards,

Jim Cunningham

P.S.

If you get reasonably good at them, try lex instead of sed and such, on any "really huge" data collections, for speed, bc. that's where sed learned to do what it does.

"lex"'s output "table" is meant to be "passed" to a "next/higher" filter, and as such, makes analysis decisions and prioritizing more clear (weighted) and yes, trivial, toward attaining whatever goal the data analysis seeks.

Where to find a good Regex source?

I think the examples could be improved. /eg?/ would match everything that /eg*/ is said to match, and /Wil?/ would match everything that /Wil*/ is said to match, no? So the examples don't show the difference betweem the two, but that's what examples are for, to illustrate both the normal cases and the borderline cases.

For /jim{2,6}/ how about saying "this will match a j next to an i next to 2 to 6 m's"? It took me a while to figure that out, and I still don't know if it would match 7 m's (I guess it won't--which is implied by the comment about leaving out the upper range). I'm afraid I'm giving up on the article at this point.

gdfhgdfhfhf