See Special Literals (in perldata) for what __END__ and __DATA__ mean.

#! 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]

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.

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.

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.

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.

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

__DATA__ defines a kind of "pseudo-file", which may be useful for debugging. You might want to check this (search for "__DATA__" on that page).