Since you have already written the code that illustrates
the issue you wanted to test, you are within reach of an
answer to your own question. A little fiddling and:
use strict;
my @restricted_words = qw (funk shucks crud);
my $word = 'crudshorts';
if (grep $word =~ /$_/, @restricted_words){
print "wash your mouth out!\n";
}else{
print "Such a nice boy\n";
}
and run it to see that you are not as nice as you hoped.
Update: The above example includes
a correction I made after chipmonk
graciously pointed out a goof-up;
a correction which turns out
(quite by coincidence -- I swear it)
to be just what he suggests at the top of
his response to this item.
BTW: The ultimate robustness of this approach is perhaps
open to question.
I have long since stopped trying to memorize the manuals
and docs. While working on a project
I just keep a test.pl script open in my editor
and a command line window at the ready so I can
test things on the fly. For questions like this it is
much faster than trying to sort out the answer
by reading the docs.
Actually, expressing my questions by writing a few lines
of script to illustrate the point of ignorance is often
a very helpful exercise in itself. And I remember
the answer
better because I took a moment to write out the
sample code and then got instant response from the
command line (often impossible in the context of a larger
project).
I also keep test.pl and a command line window at the
ready while reading through Perl Monks. :-)
All in all, a highly recommended working style. Try it.
The quick validating feedback in the midst of a larger
project is very satisfying.
You may find it soon becomes second nature.
As Saint Larry says, "Perl is an
empirical science." That means you verify an assertion,
frame a question,
or test a theory by actually running some code.
------------------------------------------------------------
"Perl is a mess
and that's good because the
problem space is also a mess." - Larry Wall
|