...and the lack of testing shows.

syntax error at 766040.pl line 7, near "close"

You're missing a terminal semicolon at the end of line 6.

where file.txt is:

001: january
002: february
003: egypt
004: moon
005: saturday
[download]

The presence or absence of the line numbers reflects laziness and slow downloads but makes no difference here.

Suggestion: Use 3-arg opens and test each one (...|| die "Can't open $file: $!\n";.

Also, IMO, McDarren's response below strikes an appropriate chord. If the list of "wanted" words is in file.txt, then testing for their presence merely burns cycles and inconveniences electrons to no purpose whatsoever.

Hence, one might infer that OP failed to specify the issue adequately and that leads to another question: Is the intent to find the "wanted" words *anywhere* within the text or is it to test the text, line-by-line, and report per-line. One might guess from OP's wording that it's the former < update for clarity (in which case, slurping the file is fine [size issues aside] but would NOT be a good approach in the latter case ). but In /update> any case, leaving the reader guessing doesn't always get the best answer.

But, all that said, a question (perhaps ignorant) for akho: why scalar <$file>; for this application?