in reply to What does this mean?

From perldata,
...the tokens __END__ and __DATA__ may be used to indicate the logical end of the script before the actual end of file. Any following text is ignored...
Text after __DATA__ but may be read via the filehandle PACKNAME::DATA

So essentially sticking __END__ at line 5 in your script tells the perl interpreter that is the end of your script. Or to put it another way, every line after line 5 is now "commented out".

The __DATA__ token isn't usually used much in real-world tasks, but I think is very useful for creating a self-contained portable example of an issue you might be having, which you can then include with your question on PerlMonks.

#! usr/bin/perl
use strict;
use warnings;

my $search_term = 'Smith';

#no need to open the DATA handle, you can simply start reading it...
for my $line (<DATA>){
    print $line if $line =~ m{$search_term} ;    
}

__DATA__
Fred Smith
Jane smith
Bob Smitters
Joe Smith


__END__
This is the output I'm getting:
C:\Temp>perl test.pl
Fred Smith
Joe Smith

But I was expecting:
Fred Smith
Jane smith
Joe Smith

[download]

Replies are listed 'Best First'.
Re^2: What does this mean?
by almut (Canon) on Mar 01, 2010 at 11:40 UTC

    It's maybe worth noting (could be misunderstood from your example) that sticking __END__ after a __DATA__ section does not end __DATA__, but rather is being read as part of the DATA lines.

[reply]
Re^2: What does this mean?
by bart (Canon) on Mar 01, 2010 at 12:49 UTC
    But I was expecting:
    You did a case sensitive match for "Smith", so it correctly skipped over "smith".

    You can try m{$search_term}i instead, for case ignoring matching.

    BTW Do you have anything against slashes for regular expressions? It's the default, and it's what people are used to: /$search_term/i

    Changing it without reason is unnecessarily obfuscating.

[reply]
[d/l]
[select]
      BTW Do you have anything against slashes for regular expressions? It's the default, and it's what people are used to: /$search_term/i

      Changing it without reason is unnecessarily obfuscating.

      Far from obfuscating regexps, alternate delimiters to '/' can help to clarify. From perldoc perlre:

      Modifiers are usually written as "the /x modifier", even though the delimiter in question might not really be a slash.

      . . .

      You can use The /x modifier to break up your regular expression into (slightly) more readable parts.

      . . .

      Taken together, these features go a long way towards making Perl's regular expressions more readable.

      From the Perl Cookbook (1st ed.) Recipe 6.4 Commenting Regular Expressions:

      For aesthetics, the example uses alternate delimiters. When you split your match or substition over multiple lines, it helps readability to have matching braces. Another common reason to use alternate delimiters is when your pattern or replacement contains slashes, as in s/\/\//\/..\//g, alternate delimiters makes such patterns easier to read as in s!//!/../!g or s{//}{/../}g

      Slashes may be what most of us are used to seeing in single-line regexps, but alternate delimiters have their place too.

[reply]
[d/l]
[select]
      You did a case sensitive match for "Smith", so it correctly skipped over "smith".
      You can try m{$search_term}i instead, for case ignoring matching.
      umm... yes. That was supposed to be a code example that one might use when posting in SoPW... So often there are questions that are unclear.

      When you have all 3 aspects of the problem
      1. real code that demonstrates the problem
      2. Expected Output
      3. Actual Output the OP recieves

      its far easier to figure out what they are trying to do and where they have come unstuck...

      BTW Do you have anything against slashes for regular expressions?
      No, not really, I just prefer using curlies. Each to their own I guess...

      Changing it without reason is unnecessarily obfuscating.
      I see your point.

      Update: Addressed bart's second point.
[reply]

      Thank you all for the support.
      I think much of the information on perl is present on perldocs..Thanks once agan...

[reply]

In Section Seekers of Perl Wisdom