UNIX for Dummies Questions & Answers

Trying to understand what's happening here, but I cannot figure it out.
I'm reading Mastering Regular Expressions, by Friedl, and he uses this as an example of how to grab quoted text:

Code:

egrep -o '"[^"]*"' ~/File.txt

...should pull in any quoted phrases. Match a literal double-quote, match anything not a double-quote until you hit the next literal double-quote.
But, he says [^"]* can match a newline, thereby returning quoted text even if it crosses lines. If you want to keep it from crossing lines, you should use this:

Code:

egrep -o '"[^"\n]*"' ~/File.txt

But this is where my head starts to hurt because a star should never fail, right? In other words, if it hits a newline, isn't a newline zero (or more) occurrences of 'not a newline', thereby allowing the regex to keep chugging along?
But looking at the difference between what each regex returns, the differences don't seem to have anything to do with newlines. Check out the different results each regex pulls from this snippet:

Code:

egrep -o '"[^"]*"' ~/File.txt
"What uncouth dialect is that?"
"The Doric."

egrep -o '"[^"\n]*"' ~/File.txt
"The Doric."

Why does the second regex miss the first quote? The first regex returns about twice as many hits as the second one, and they all appear to be valid, single line quotes.
I should also mention that I'm not trying to accomplish anything. My interest is purely academic, and I'm a total noob.

GNU grep
OS X 10.6.8
Original file is plain vanilla ASCII, each line ends in a newline.

Regexes are greedy, so only on the last line matches the class of no double quotes and no newlines.
Try options -P or -z of grep to match across newlines.

B.t.w.: this is an area were the regex functionality differs a bit between grep, awk, Perl, etc.

egrep/fgrep/grep is a line-oriented tool. The regular expression will NEVER span across lines because grep operates one line at a time.

The reason the regular expression with the bracket expression [^"\n] does not match "What uncouth dialect is that?" is because within the bracket expression the backslash ceases to be a special character; the sequence \n in [^"\n] does not represent a newline character, but a forward slash and an n, two separate characters. Since this translates to any character that is not a quote, backslash, or n, the n in "uncouth" prevents the match from ocurring.

For the nitty gritty on bracket expressions, refer to Regular Expressions, from which the following is extracted:
Regards,
Alister

@alister: My bad! Greedyness has indeed nothing to do with this problem. Thanks for putting that right.

@alister, it may be interesting to add that like grep, sed is also line oriented, but that it does have the ability to match \n which can occur through the use of N or H commands. But indeed \n loses its meaning withing square brackets. \n is not part of POSIX regular expression, but for this POSIX sed has an addition:
sed: regular expressions

POSIX awk goes even further, as it extends POSIX regular expressions, to include the C-language extensions and they are valid within bracket extensions...

awk: regular expressions

To that list of sed commands which can inject a newline you can also add y, G, and s.


ex also has its own flavor.

Even within the confines of the POSIX standard, there are quite a few RE flavors to master: basic, extended, sed, AWK, and also ex. Add to that proprietary extensions by implementations of the standard tools and the dynamic programming languages and you have quite a melange.

Regards,
Alister

Wow, yes I did know about the bracket rule, and should've thought of that. On the other hand, he's using it as an example in the book. Perhaps it's meant for perl, (and why the -P flag was suggested)? That's the thing I'm having the most trouble with, is understanding what works with what.
It even turns out that there are different greps, who behave differently! A lifetime of Mac OS use has not prepared me for unix.