note
ww
[brusimm], this seems a good start; even <b>meritorious!</b> <br> <br> ...sufficiently so that I hope I will not offend with observations on a few things that seem to me to be shortcomings.
So, if you care, <readmore>
<p>You seem to be a bit categorical when, even in the context framed by your RFC, you might do better to qualify remarks. For example, <blockquote>"Patterns are used to locate text strings within text lines."</blockquote>... to which I say, 'yep, <b>but</b> also across line-endings and not necessarily <b>only</b> for what the target audience might consider a "text string"</p>
<p>I would urge <b>great</b> care in language in comments, as well. For example, in "example 1" <blockquote><tt> 004: print "There, brus showed up.\n" ; # if the pattern is found, print it!</tt></blockquote>
You mileage may vary, but I read the comment as at least mildly <b>MIS</b>leading because of what I see as <i>potential confusion on the reader's part</i> between the hardcoded output "brus showed up" and the captured "brus"</p>
<p>BTW, here or, at latest, the next section might be the time, despite the added complexity entailed, to introduce the wisdom of testing whether a match actually <b>DID</b> succeed.
<blockquote><c># Possible revision, example 1
$_ = "I logged in as brusimm and found that I had email."; # Test string
if (/brus/) { # Pattern: brus
print "There, our pattern showed up in our string.\n" ; # Tell user
} else {
print "No match in our string for our pattern.\n"; # As you'll see...
}</c></blockquote>
where the truncated comment might be used to foreshadow a later segment of your tut that demonstrates the dangers of using a <b>presumed but untested</b> match.</p>
<p>I hold (again, YMMV) that economy of language helps the reader to understand.</p>
<p>Hence, IMO,
<blockquote><tt>Let’s say we knew whoever wrote the line, had issues with typing, for example, I had too much coffee and wrote the following:</tt></blockquote> might better be phrased (trying not to impose too much of a <strike>nitpicker's</strike> editor's judgement on your bid to be "user friendly):" <blockquote><tt> Let's say I'd had too much coffee, and might have mis-typed the test string.</tt></blockquote></p>
<p>I'd also urge greater care (or, perhaps, selectivity) in language such as: <blockquote><tt>Notice the control character of “s” before the forward slash. Check it out with this script:<br>
<br>
001: # example 3<br>
002: #<br>
003: $_ = "I logged into bruuuusimm and saw I had email.\n"; # original error<br>
004: print $_ ; # printing proof of error<br>
005: if (s/bru*s/brus/) { # fixing it<br>
006: ....<br>
</tt></blockquote></p>
<p>While your reference to the "s" before the slash as a "control character" is arguably CORRECT, as a tutor you may want to consider your audience's preconceptions/prior knowledge/frame of reference.
Many who are new to regexen may have sufficient computer experience to simply slide over a semi-familiar phrase, confident in a preconception that a "control character" is a byte in the range 0-0x20; something quite different than what you intend.</p>
<p>I could go on a bit more, but perhaps this is a better time to simply offer the thoughts that:<br>
1. Very few are their own best editors.<br>
and,<br>
2. Work with someone whose language skills rival your coding skills.</p>
</readmore>
595955
595955