As others have pointed out, part of the problem is having  while (<FH>) in two different places -- this makes it a lot harder to control what's going on.

Even though the data is not XML, it appears to be good enough as SGML. There is SGML::Parser, if you feel so inclined, but with stuff like the example you showed, I tend to be more "trusting" of the data (especially if I have already validated the data separately, e.g. using James Clark's SP package), and I would use some simple perl-isms to chunk my way through it (after I have used a separate, simple perl script to scan the data and make sure my simplifying assumptions are correct). For example:

if ( open( FH, <data.sgl")
{
    local $/ = "</ref>\n"; # make close-tag the input rec. separator

    while (<FH>)   # now read a full "ref" element into $_
    {
        next unless ( m{<aulist>.*?$search.*?</aulist>}is );
        # now split the ref element up and print it
        # <strike>(I'll leave that as an exercise...)</strike>

        # Since you have a finite number of things you want
        # to put into your output listing, it'll be easiest
        # just to look for those things:

        for my $fld ( qw/author year source keys title/ ) {
           @{$data{$fld}} = m{<$fld>([^<]+)}ig;
        }
        print_record( \%data ); # all hash elements are array refs
             # (some may be empty/undef, some may have 1 item)
    }
    close FH;
}
else 
{
    die "Unable to read data.sgl\n";
}
[download]

That assumes that the search term only applies to the contents of the "author list" sub-element within the ref, but it should be easy to see how it would extend to other sub-elements like title, etc.

I'm not sure how much you should worry about checking the content of $search before passing it into a regex match... using the "m{...$search...}" type of usage shouldn't risk any real trouble.