Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As <a href="https://stackoverflow.com/a/14941006/368630">Jim Davis</a> pointed out, <code>$</code> matches both the end of the string, or before the <code>\n</code> character (with the <code>/m</code> option). (See the <a href="http://perldoc.perl.org/perlre.html#Regular-Expressions" rel="nofollow noreferrer">Regular Expressions</a> section of the <a href="http://perldoc.perl.org/perlre.html" rel="nofollow noreferrer">perlre</a> Perldoc page. Using the <code>g</code> modifier allowed it to continue matching.</p> <p>Multiple line Perl regular expressions (i.e., Perl regular expressions with the new line character in them even if it only occurs once at the end of the line) causes all sorts of complications that most Perl programmers have issues handling.</p> <ul> <li><p>If you're reading in a file one line at a time, always use <code>chomp</code> before doing <strong><em>ANYTHING</em></strong> with that line. This would have solved your issue when using the <code>g</code> qualifier. </p></li> <li><p>Further issues can happen if you're reading files on Linux/Mac which came from Windows. In that case, you will have both the <code>\r</code> and <code>\n</code> character. As I found out recently in attempting to debug a program, the <code>\r</code> character isn't removed by <code>chomp</code>. I now make sure I always open my text files for reading</p></li> </ul> <p>Like this:</p> <pre><code>open my $file_handle, "&lt;:crlf", $file... </code></pre> <p>This will automatically substitute the <code>\r\n</code> characters with just <code>\n</code> if this is in fact a Windows file on a Linux/Mac system. If this is a regular Linux/Mac text file, it will do nothing. Other obvious solution is not to use Windows (<strong><em>rim shot!</em></strong>).</p> <p>Of course, in your case, using chomp first would have done the following:</p> <pre><code>$cat file line one line two line three line four $ perl -pe 'chomp;s/$/addthis::/g` line oneaddthis::line twoaddthis::line threeaddthis::line fouraddthis:: </code></pre> <p>The chomp removed the <code>\n</code>, so now, you don't see it when the line print out. Hmm...</p> <pre><code>$ perl -pe 'chomp;s/$/addthis/g;print "\n"; line oneaddthis line twoaddthis line threeaddthis line fouraddthis </code></pre> <p>That works! And, your one liner is only mildly incomprehensible.</p> <hr> <p>The other thing is to take a more <em>modern</em> approach that Damian Conway recommends in Chapter 12 of his book <a href="http://shop.oreilly.com/product/9780596001735.do" rel="nofollow noreferrer">Perl Best Practices</a>:</p> <blockquote> <h2>Use <code>\A</code> and <code>\z</code> as string boundary anchors.</h2> <p>Even if you don’t adopt the previous practice of always using /m, using ^ and $ with their default meanings is a bad idea. Sure, you know what ^ and $ actually mean in a Perl regex<sup>1</sup>. But will those who read or maintain your code know? Or is it more likely that they will misinterpret those metacharacters in the ways described earlier? Perl provides markers that always—and unambiguously—mean “start of string” and “end of string”: \A and \z (capital A, but lowercase z). They mean “start/end of string” regardless of whether /m is active. They mean “start/end of string” regardless of what the reader thinks ^ and $ mean.</p> </blockquote> <p>If you followed Conaway's advice, and did this:</p> <pre><code>perl -pe 's/\z/addthis/mg' myfile.txt </code></pre> <p>You would see that your phrase <code>addthis</code> got added to only to the end of each and every line:</p> <pre><code>$cat file line one line two line three line four $ perl -pe `s/\z/addthis/mg` myfile.txt line one addthisline two addthisline three addthisline four addthis </code></pre> <p>See how well that works. That <code>addthis</code> was added to the very end of each line! ...Right after the <code>\n</code> character on that line.</p> <p>Enough fun and back to work. (Wait, it's President's Day. It's a paid holiday. No work today except of course all that stuff I promised to have done by Tuesday morning).</p> <p>Hope this helped you understand how much fun regular expressions are and why so many people have decided to learn Python.</p> <hr> <p><sup>1.</sup> Know what <code>^</code> and <code>$</code> really mean in Perl? Uh, yes of course <strong><em>I</em></strong> do. I've been programming in Perl for a few decades. Yup, I know all this stuff. (Note to self: <code>$</code> apparently doesn't mean what I always thought it meant.)</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload