Slashdot Mirror
Mastering Regular Expressions
My first suspicion, I admit, was that I was facing one of the countless "man page reprints" that you find these days. It was only after reading the book that I eventually understood: before then, I had had no idea of what regexes were really about.
What it's about The book is logically divided into three parts: the first one (Chapters 1, 2 and 3) introduces the reader to the basic concepts of regexes, building a common ground upon which the subsequent chapters will be based. The introduction is clear and straightforward, and lets the readers quickly grasp the key points in the regex business. This part is more or less a good summary, presenting information that can be found also in existing manual pages (albeit presented in a distilled form, which lets you perceive that the author has very clear ideas about the matter). If you already know something about regexes, you could skip this part entirely -- even if reading it turns out to be a nice occasion to brush up and overhaul your knowledge.
The second part (Chapters 4, 5 and 6), is the one that struck me most for the depth of provided information and the richness of though. Rather than throwing at the reader usage dictates on one or another regex flavour, the author explains with a wealth of details the inward mechanisms which make regexes run and how you can exploit such knowledge to write better expressions.
Chapter 4 presents the different families of regex processing engines (namely, DFA, traditional and POSIX NFA), whose internal behavior differs so greatly that writing a regex in the appropriate way can make a substantial difference in both efficacy and efficiency. If you thought you knew it all about greedy and lazy regex operators, possessive quantifiers, backreferences and lookaround, you'd better think again: I was pleasantly surprised to discover how ignorant I was (to be honest, I had never heard of lookaround operators before!).
Chapter 5 slows down a little bit to let the reader absorb the massive previous chapter. Some simple (but still tricky) examples are presented, showing how to apply the techniques explained up to this point. A couple of examples are perhaps too contrived (ever needed to match aligned groups of 5 digits in an unspaced stream of characters?), but it is instructive anyway to follow the reasoning behind the construction of a complex regex.
Chapter 6 focuses on efficiency, considering how backtracking and matching can drive your regex engine to exponential complexities. Optimization techniques are then presented, first by explaining the automatic optimizations performed by the most common regex engines and then by giving a practical list of hints that you can follow to be sure that your expression will run as fast as possible. Again, I was quite surprised to find out how small changes in a regex can make such a big difference to the engine (and give rise to noticeable performance penalties if ignored).
What I absolutely liked most was that the author explains exactly why a certain optimization works, based on the information given in Chapter 4 (and provided that you have been able to assimilate it in the first pass). Finally, a paragraph entitled "Unrolling the loop" really put me in a good mood, reminding me of the past times of "old school" asm programming.
The third part of the book devotes three chapters to PERL, Java and .NET, respectively. Each chapter goes through the syntax and features of regexes for each language: while the information provided on Java and (VB).NET is quite commonplace, in the case of PERL the author deals with aspects rarely covered elsewhere, like dynamic regexes, embedded-code constructs, regex-literal overloading and specific optimization techniques.
What's to like In one word: insight. The author is definitely knowledgeable of regular expressions and the whole book is filled with thoughtful suggestions and hints. Still, a friendly and straightforward writing style makes reading pleasant and seldom boring (well, you wanted details, didn't you?) while you learn internal regex mechanics rarely available elsewhere.A further nice point is the broad view offered to the reader, starting from regexes in general and focusing on specific flavours only in the final part of the book. The second edition also offers up-to-date information, covering the .NET framework and the latest versions of PERL (5.8) and Java (1.4).
What's to consider Despite the book's reassuring conversational tone, dealing with such a specific topic with so many in-depth details might sometimes become boring, especially if you do not have a strong interest in getting the most out of regular expressions or in knowing how they internally work. If you are just an occasional regex user and dwell in manual pages, you can probably live without this book. Also, it is a pity that specific sections on Tcl, emacs and awk have disappeared in the second edition (maybe they were not as current as the .NET framework ?) and that pcre (a C regex library) is barely mentioned. The summary Regular expressions are tied so strongly to the *nix culture that everyone who has been exposed to that culture has come to use them in a more or less conscious way. Still, most of the documentation around lags on basic features and presents only the most common regex operators. Mastering Regular Expressions is the book to read if you want to go further and get serious about regexes: even if extreme optimization might not be a big concern today, understanding how regex engines work under the hood greatly helps also in creating everyday small expressions. Table of Contents Preface
Chapter 1. Introduction to Regular Expressions
Chapter 2. Extended Introductory Examples
Chapter 3. Overview of Regular Expression Features and Flavors
Chapter 4. The Mechanics of Expression Processing
Chapter 5. Practical regex techniques
Chapter 6. Crafting a Regular Expression
Chapter 7. Perl
Chapter 8. Java
Chapter 9. .NET
You can purchase the Mastering Regular Expressions, 2nd edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
when figuring out the lameness filter
This one is a great addition to the book shelf, you all know how to do certain things regular expression but this book clarifies nicely why you are actually doing it. Also, it introduces nice advanced concepts which occasional regex users might not have come across before.
There is no god
This sounds like a nifty tool for those who have to switch programming environments quite often. I always find myself going back to the books when I either have to write a regex myself or decypher someone elses crazy looking expression.
--------
Free your mind.
I read the first edition of this book - it was great, and completely changed the way I handled (and understood) perl regular expressions. It's tempting, after reading this book, to try to apply regex's to everything! Friedl had an example of a huge, horrible (but efficient) regex to parse mail headers in the first edition - my advice on that is, don't try that at home! Interspersing procedural logic with the regex's tends to make much cleaner and more readable code...
Energy: time to change the picture.
I am so happy that this book is out. I love regular expressions (first saw them in Perl and JavaScript), and I considered buying the first edition from O'Reilly last year, but I thought that it would be best to wait and get the next edition (plus I had about 5 other O'Reilly titles to read at the time). I wish that there was better support for regular expressions in languages like C/C++. Does anyone know of a good library for it because there is no support for it in the language that I know of? Thanks.
Can anyone that's read this describe what's changed from the first edition? Is it worth shelling out the cash if you already have the first one?
objRegExpr.Pattern = "I could use this book, I don't tend to get the most out of my regexs."
strSearchOn = "I could use this book, I don't tend to get the most out of my regexs."
Set colMatches = objRegExpr.Execute(strSearchOn)
Here
Can anyone tell me:
Is there a simple way to do perl -p -e 's/\r\n/\n/g; s/\r/\n/g' with sed?
Do I need to buy this book?
but instead I *
Best Windows Freeware
Thats shell expansion, not a regex. * is a quantifier in regex, and needs to have something to it's left to quantify (such as .* or [0-9a-f]*).
Don't most languages just come up with their own, especially with anoying things like the LF/CR problem?
-Libertarian secular transhumanist
I just purchased an almost new copy on Half.com for under $15 including shipping. There are still a few left at prices far lower than amazon.com or bn.com. Here is the half/ebay link.
I read the first edition and loved it. Can anyone who has read both editions say if it's worth buying the second edition?
My only complaint about the book is that non-techies looked at the title when I was reading and said, "Aren't 'Hi there' are 'How are you?' regular expressions?"
It's always surprised me when I see intelligent people write "PERL" when they refer to Larry Wall's programming language.
From the Perl FAQ, General Questions About Perl:
What's the difference between "perl" and "Perl"? :-) Larry now uses ``Perl'' to signify the language proper and ``perl'' the implementation of it, i.e. the current interpreter. Hence Tom's quip that ``Nothing but perl can parse Perl.'' You may or may not choose to follow this usage. For example, parallelism means ``awk and perl'' and ``Python and Perl'' look ok, while ``awk and Perl'' and ``Python and perl'' do not. But never write ``PERL'', because perl isn't really an acronym, aprocryphal folklore and post-facto expansions notwithstanding.
One bit. Oh, you weren't talking ASCII?
You can read the entire FAQ if you like.
Which isn't actually a regex at all.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
This is no "Learn Regex in 21 Days" or "Regex for Dummies" book with lots of tips on page 400 about how the | is useful for finding Jones OR Smith. If you haven't gotten that down yet, this book's not for you.
As the reviewer says, this is a very worthwhile cover-to-cover read which will turn your empirical experiences with regex into a more structured understanding of the science and engineering of advanced regex. As a reference on my shelf, it sits comfortably next to Knuth's AoCP and Foley & van Damme.
[
I first started reading this book via netLibrary through my school's library. Just the first two chapters are enough to explain regular expressions to the point where one can use them effectively in programs. The remaining chapters expand on this information and discuss language specifics. I bought a paper copy to have on my shelf, and I constantly find myself referencing it.
To those at universities, see if your school offers netLibrary-based books. It's easy to read and it's free.
-- "Complacency is a far more dangerous attitude than outrage." -Naomi Littlebear
Agreed. Especially since the reviewer mentioned that Tcl/emacs/awk/pcre regex's were not covered in any detail in this edition. A small appendix at the end summarizing the syntax in those languages would have been helpful to many, I'm sure. It would be nice if O'Reilly did publish such a thing as errata, so we could print it out and tuck it in the back cover or something.
Constitutionally Correct
Now, I thought I was reading a simple article about a programming book review. And here I come across this thread of epic mirth. Somehow you have single-handedly crafted a finely-tuned piece fun-joy from what was a rather mundane topic. I just have to page my boss back to the office to see this! Gather round the water cooler old salts and let me spin a comedic yarn I saw this day on Slashdot. Using an asterix to finish a sentence we would have all seen as being finished in a different manner? Well sir, someone set you up the bomb. You have taken that bomb, added the asterix into the mix and exploded laugh-shrapnel into Slashdot proper. I couldn't even scroll down without getting struck in the eye with a piece of your fun-bomb. Mods, mod this man's excursion into the comedy arena as +5 StopItHurts. Here we sit, emotionally spent and basking in the aftermath of your comedic genius. Thank you kind sir, thank you.
The article mentions pcre (I believe that's the Posix C Regular Expression library).
On most systems, use `man regcomp` to see how to use regcomp, regexec, regerror, and regfree.
Essentially, you first compile the regular expressioin into a binary format with regcomp(), then use regexec() to match it against a string. It's all a little awkward to use until you get used to it.
Which isn't a big deal, I guess.
Mastering Regular Expressions is now in its second edition. Mr. Friedl has posted a nice writeup about what's different in the second edition.
--
the strongest word is still the word "free"
I'd be happy if the editors could master spelling and grammar
s/\A(.*?)\s+(.*)\Z/In soviet Russia, $2 $1s you!/i;
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
I know from my own experiences that writing a regular expression to describe something is not always as easy as it would seem at first glance. I found it difficult to write a regular expression to define a c-style comment: /* comment */ Well, not impossible, just more difficult that I thought it would be. I posted my thought process about how I constructed a regular expression to pick out a c-style comment on my website. It's the kind of thing I like to ask interview candidates.
I'm rather sure the author was after Perl Compatible Regular Expressions.
Regex Coach is a great free tool for learning about regular expressions and constructing them interactively. Both Linux and Windows versions are available.
Floating face-down in a river of regret...and thoughts of you...
... the book to write this up, and he got it out within minutes of the article going up. It's not informative whatsoever. Come on folks, let's spend the mod points a bit more carefully.
I'd be interested to check that book out as I use reg expressions a lot in PHP. But for those of you looking for a resouce online check out RegExLib. I use it often when I'm having trouble putting an expression together and have found it extremely helpful.
Going from windows to unix one of the things I liked most about unix was the wide spread usage of regex in various applications. Quite powerful.
Thats a big regex
stupid filter wouldn't let me paste the regex here XD
But what drives me nuts about using regexps is how they differ slightly from implementation to implementation. Even though the perl regexp's tend to be the de-facto standard, the perl people are frequently adding stuff to their regexps. Some regexp implementations require you to escape open-paren to get the special meaning, and not escaped to match an open paren. Others require just the opposite. Madness!
... is that I can never get it back from people who "borrow it for a few days".
Regex rules, but I wouldn't know anything if it wasn't for this book in portuguese: http://guia-er.sourceforge.net/. The printed version is always with me wherever I go.
The Boost C++ libraries have a regular expression package. Take a look at http://www.boost.org/libs/regex/index.htm
Caution: Do not stare into laser with remaining eye.
I downloaded this from edonkey a while ago... *yawn*
Regular expressions are extremely powerfull, but that cryptic line of text is out of control. I mean, you have to be an expert in regular expressions to do the most rudmentary things. I've been using them on and off for years, and every time I find myself studying the book for hours just to write a simple search and replace.
I guess if I used them on a daily basis, I would be better off, but how many programers find a need for that?
I think they should offer a form of regular expressions in a longer form with easier to read syntax for the casual user.
Just my 1/2 cent.
Does anyone here know how to do multi-line regexes in perl? I've seen the notation on how to do it (Mastering Regular Expressions has one paragraph for it), but nothing seems to work...
Slashdot's first reaction to VMware
The problem with regex's is that if you don't use them often, you forget a lot of the finer details. They are not self-documenting at all. I think something like "generators" used in some of the compiler tools floating around are more intuative. For example, you can define a "LISP-lite" language like this:
statement -> (command params)
statement -> (command)
params -> params params
params -> constant
params -> variable
params -> statement
Table-ized A.I.
All the spam I get these days contains little lines of random (or apparently random atleast) alphanumeric characters at the bottom, for the most part simply capital letters, although some are more complex. Some have random strings of alphanumeric characters longer then 50 characters... Has anyone else noticed these lines at the bottom of spam? Surely it would be fairly easy to filter spam at the MTA level using regex on these strings...
-------------------------------------------------
All you have are zero-or-more "+", one-or-more "*", conditional "? or sometimes "[ ]", scan-sets "[a-zA-Z]", grouping "()" or "{}", non-CFG count range {}2,3, sentintel chars ^ $ etc., place-holders for replacement, dont match "~" or "!", match any single char ".", and maybe a few more odds-ends. It's these bozos that think "regexp" sounds cool, but doesn't want to learn what they are. In general, these generalized extended regular expressions are easily implemenatable w/ efficient DFA and NFA->DFA conversion (i hate that algorithm!!!). If you need a 500 page book on regexps, you might want to have a look at a good compiler book (red dragon, etc.) first. Full non-CFG languages are so much more powerful than any regexp could ever dream of being, and more importantly they can have state.
The biggest trick the devil pulled was letting lawyers become politicians so they can write the laws.
I also have this book [actually right next to me]. I'd put off learning perl [and indirectly regexes] for some time, because... well, I was a windows admin by trade. Now that I do other [actual] work, time came to pickup on some other tools.
Even having not dealt with regexes pretty much at all, the book was very easy to get into. The first few chapters go through the basic matching structures, along with requisite history. All of the points are done with understandable real life examples, with diagrams and [a small amount] of actual code. The later chapters go through individual languages, and goes through which features are there, what the nuances are, and a few of the gotchas. I must admit that I probably learned more useful things about perl from this book than from any other source. There is also a large section [which I did not read, and caanot comment on] which actually details the nuts and guts of regexes.
All and all, it's easily the best instructional [as opposed to reference] text I've ever purchased.
I wish there was an online tool with a simple web interface that would let you craft regexes using menus.
perl isn't really an acronym, aprocryphal folklore and post-facto expansions notwithstanding.
... cold ...
So Perl doesn't stand for "Practical Extraction and Reporting Language?" My world has been blown apart. The sky is spinning. So
My first suspicion, I admit, was that I was facing one of the countless "man page reprints" that you find these days.
No, that would be OReilly's in a nutshell series of books..
Kudos to you for the best post I've seen in this bore-a-torium all day.
yeah, those are my favorite:
"It doesn't get any more serious than a rhinocerous about to charge your ass"\
rofl
there's another with a pirate that's funny as hell too
The reviewer forgot to mention the wonderful errata list of the book! Can be found here.
(to be honest, I had never heard of lookaround operators before!).
Gezzzz, This guy hasn't even heard of lookaround operators before? What a clueless fool! He should be driven from /. after being tarred and feathered!
Everyone knows that a lookaround operator is that guy that goes into the bank first to make sure that there aren't any armed guards or policemen/women getting their paychecks deposited.
LongTail SSH Brute Force analysis tool is here!
If you want to have something more powerful than regexprs, and still have it as an interpretter, you might have a look at an interpretting parser that I wrote: IParse.
Sure smells like a regex alias to me.
There are no karma whores, only moderation johns
I never really thought you could fill a book about regular expressions, but this one manages to accomplish this while at the same time being very interesting. This is absolutely required reading if you know "enough to get by" with regular expressions. Chances are, until you read this, you're making a ton of common mistakes and you don't even know about it.
Josh Woodward
Yea, the post should at least bust on Microsoft, make some kind of esoteric unfunny comment about CowboyNeal, or praise CmdrTaco to get +4 Interesting. Some moderators are smoking crack today, and they're not sharing.
For those who don't want to buy a book, here's a nice page with pre-built regexps for doing all sorts of things: RegexLib.
Go here for teh [sic] funny.
Where as this is a comment
This is a quick trick for quickly commenting out a small section, yes I know #if 0 works well and this doesn't nest but I like it for small code because the editor I use changes the color when it's a comment etc. The point is that if you are already in a C++ comment then you can't enter a C comment. It's also fairly easy to write you're own finite state machine to print out comments, but of course that doesn't plug into anything.
The re-builder mode is great for debugging regexps in Emacs. This is the latest version as far as I can tell: re-builder 1.2
Your password has expired, please login to change it.
I have a previous version of Friedl's book and found it needlessly confusing. The author's examples often leave much to be desired. I have no doubt that all of the information about regex is somewhere in the book, but it takes an extraordinary amount of work on the reader's part to extract it.
You can hand me a box of wrenches, but that won't tell me how to fix a car. ;-)
maybe where you come from
awk
sed
grep
sam
not a perlism in sight
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
There are no ".NET framework" languages. There are languages that target the Common Language Runtime, or the CLR. The .NET Framework is nearly a class library like the JDK/JRE. If he doesn't even know that, why should I trust his book review?
How about something like this: m|/\*.*?\*/|s
pb Reply or e-mail; don't vaguely moderate.
www.bookpool.com
Mastering Regular Expressions, 2nd Edition
Our Price: $24.50
Bookpool is consistently the cheapest place to buy technical books. And no, I am not affiliated with them in any way.
Regexes are a little cute toy in a programmer toolbox. It's nice to use, but you'll be cursed forever by who mantain your code. Better use it just in weird string-replaces inside your text editor, throwing out after the use. A great refactoring tool.
From formal point of view, regular expressions in Perl (PCRE) are no longer true regular expressions. Since Perl 5.6 and the introduction of look-ahead/subexpression clauses, it is possible to match expressions of classic context-free grammar of correctly parenthesized clauses.
I therefore suppose that one day somebody will implement a CFG parser entirely using PCRE engine (and most probably on a sigle line ^__^).
...about switching programming environments. Right now there's some discussion about problems in regex engines which follow you around as you switch environments, due to problems in the engines.
Curent versions of glibc (apparently) made some inefficient design choices in their regex engine. When other tools such as sed switched to using glibc's version, their performance dropped quite a bit, leading to a couple of bug reports.
The interesting thing is, one of the messages in the bug report mentions this book. It had been a few years since I covered DFAs and NFAs in college, so I got a copy yesterday. Came back home to find this review on /.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Mastering Regular Expressions:
Repeat after me:
"I'm so hungry, I could eat a horse."
"It's been raining cats and dogs."
"I'll sleep with you when Hell freezes over."
And my personal favourite:
"Oh look, Hell just froze over!"
And recursion is lots of fun, but I use REs to recognize and extract tokens and boundaries, because it's so easy to write and change simple REs.
There is a middle way between overly complex REs which mere mortals cannot read nor safely modify, and overly complex parsers that never take advantage anything more functional than getc().
The very fact that both vi and emacs support regular expressions must mean they are a best-in-breed tool, because if there was a way for those two communities to disagree, they would have done it.
I love the fact that I can use the same expressions with grep, sed, vim, Perl, and Java. that being said, however, the critics are who warn that regex can be over used are correct: regex's are difficult to debug and to maintain, so don't go overboard.
Yes, actually. Older FORTRAN codes (that have been slowly added to/modified over time) especially exhibit this kind of behavior thanks to formats that allow you to specify columns for output. The numbers actually run into each other on the line, and the only way to read the file is to know which column the data you want is in. I would never discount any regular expression example as contrived. Somewhere, someone has developed a program that uses that formatting in an input or output file, and someone else might need to be able to speak it's language in an automated fashion.
what did one regular expression say to the other?
.*
Geez, when I bought it at borders the guy rang up the order practically bowed and scraped.
"Today I got roughly 4 first posts but then slashdot wouldn't let me post anymore. So thats enough trolling for one day." - rkz
To be honest, that this exact same post template has been moderated highly again and again in recent book reviews is becoming more humorous than anything. Unfortunately, and this is addressed to certain moderators, I believe it would be correct to say the laughing is 'at you' and your misfortune rather than 'with you'.
If you would like to confirm that you are being 'taken in', click on the link represented in the parent post by the user name to be taken to a list of this user's recent posts
There, view the user's posts made in recent book review comment threads to see this exact template used in multiple "Book Review" comment threads.
Here are several past instances of this template being used by this user:
Mac OS X Unleashed (2nd Edition)
Dynamic HTML: The Definitive Reference (2nd Edition)
Linux Network Administrator's Guide, 2nd Edition
In the future, please feel free to cite this post as a reference to inform the opinion of future Book Review comment moderators.
And they are available in all platforms and in all languages (c and c++ thru libraries), I have a suggestion:
I suggest that all programmers should program in pure regular expressions.
That way we should be able to ensure the maximum portability and clarity of our code.
No more will we have to waste our time learning the latest new thing forced on us by Microsoft or Sun -- our language can do it all!!!
-- Joe Perl Hacker
A sample chapters from the book, Java and .NET are available in PDF format from the book page on O'Reilly's site.
Hey -- I'm not dissing you -- but it was funny that you made the mistake. :-)
:-)
One thing to remember these days -- given the broad range of exposure to computers, from Grandma through systems designers, compiler writers, and formal methods gurus. The latter sets make up less and less of the community.
Although it is agreed that CFG's, regular expressions, FSM and compiler technologies are important, I'd wager that well under 1% of the online community -- and even under 5% of the 'technical' community every really had to wade through the proof that an NFA called N is equivalent to a DFA called D subject to the following blah blah blah.
If you're taking a compiler course -- I would have to assume that a pre-req was the Theory of Computation (or equivalent course). When I was that age, (here we go), Theory 1 was a 1/2 course (semester) and was the pre-req for the compiler course (along with some math courses). The compiler course was a full-course (1 yr long).
i was really excited when i first got this book, but i never have liked reading it. every few months i go back to it hoping i will change my mind, but i still hate it.
my major problem with it is the notation. he uses some symbols, like an "L" and a reverse "L" that are very light (the font) and i find it very annoying.
in general, i think that the book could be shorter. regular expressions are not very deep, and even though they are useful, a whole book is not necessary (at least for my purposes).
Finally! A book geeks can use!
Chapter One: "I have FIVE black lotuses in my main deck" is not a good way to impress girls. Niether is using the phrase "Ogg Vorbis" every chance you get.
grow the fuck up.
regexps are the least of your worries.
i've been looking at the boost c++ regex library http://www.boost.org/libs/regex/ and i'm going to give it a try. as i'm doing more c++ programming these days ( i've been lucky to have been doing perl for the last couple of years :) ), i've been looking for quality, cross-platform, license-compatible c++ classes; boost seems quite good (and it's peer-reviewed, too)
i also just found this benchmark http://research.microsoft.com/projects/greta/regex _perf.html comparing boost vs. microsoft's greta http://research.microsoft.com/projects/greta/ which gives you "all the power of Perl 5 regular expressions in your C++ applications. These easy-to-use classes let you perform regular expression pattern matches on strings in C++." (from the website)
wipe that smile
off
of
your
crazy, bald head.
Here's where I take the opportunity to direct you to my homepage link above, where you will find a set of nasty regular expressions that you can plug into Privoxy, a filtering HTTP proxy. They will rewrite slashdot's HTML markup with CSS tags, which lets you create a stylesheet to modify the look and feel of slashdot quite radically. A fun distraction if you're bored...
What website do regular expression's love?
/.
These regex books are nice to get a first grip on the topic, to see some common applications beyond del *.*.
But I personally came only past a certain level of understanding, these texts never managed to explain what NEAs are, why there are sometimes epsilon transitions or not and so on.
The big enlightening came after a great course in automata theory and formal languages (in German), thus some theoretical computer science.
After this course it was considerably easier to read the dragon book and such applied regexp titles. So I would definitely recommend to read through a book like Hopcroft/Ullmann to get the foundations right.
This year I work through a course about applied automata theory (in German) and it introduces great applications, the connection between finite automata and logic formulae, which is important for model checking and automata that do not work on words but on trees or even more complicated structures like pictures and grids. The tree automata allowed to me get a better grip about the foundations of XML, DTDs, XPATH and such.
Last year there was a course about automata theory and reactive systems (in English). which used automata on infinite words to model parallel processes, games and such. Too bad I had no time to work throught it.
So I definitely vote to go for the theoretical computer science. It makes you see certain design decisions much, much clearer.
Regards,
Marc
Although of course del * is all you need as a regular expression.
Combination - fun iPhone puzzling
del \Sigma^*