And I don't object to doing things directly, as you did, even with HTML. I have frequently edited huge piles of HTML with -pi -e 's///' but I would never recommend it (to a junior dev at least) because it's similar to recommending cleaning a loaded gun. I don't mind taking the risk, and even the consequences, myself now and then but I'm not going to suggest it's a good idea to anyone else.

OPs frequently misreport or overly simplify requirements or misunderstand the differences between the cases and unlearning a bad habit is much harder than learning the right way, so I appreciate the dogmatic as long it is also a legitimate best practice. It's easier to say always do ABC than to say you could do XYZ as long as, provided that, but beware, also note bene, caveats apply.

I don't think your advice was incorrect, I was just addressing the why be dogmatic part. :P

You're making a lot of assumptions about the data, whereas I assumed that "CAT,DOG,BIRD,COW" was just an example and not the actual input data, so we really don't know what it'll be ("be liberal in what you accept"). Knowing how to do it in plain Perl is of course useful, but personally I'd prefer the first solution people come across to be a robust one - hence the somewhat dogmatic statement, but hopefully for a good reason ;-) I also agree entirely with Your Mother's posts.

If all your assumptions hold, then sure, it's fine to use plain Perl, but even then I would have written something like the following - just one more line of code to protect against the input changing unexpectedly:

my $input = "CAT,DOG,BIRD,COW";
$input =~ /\A\w*(?:,\w*)*\z/ or die "invalid input format";
my $str = join ',', map { "'$_'" } split /,/, $input;
[download]

I did assume that the OP, since they are doing work with a database, will have a $dbh lying around. Note that our two pieces of code really aren't that different - only a couple more characters for extra protection :-) Also note that using the database driver for quoting should take care of possible quoting differences between databases.

my $str = join ',', map { $dbh->quote($_,'VARCHAR') } @values;
my $str = join ',', map { "'$_'"                    } @values;
[download]

Hi haukex,

first, I'm really sorry, I should not have used the work "dogmatic." I understand it might be considered a bit derogatory, and I really did not mean that.

Then, whether you're using the DBI quote subroutine or the core Perl solutions I suggested, you need to validate the input data beforehand anyway if it's coming from an external source.

I was perfectly happy with the solutions you suggested (and I think I said so), I only reacted to the sentence: "this is the very least you should do - don't go and try to quote the strings yourself."

Finally, I really think that somebody learning Perl and not knowing how to quote a bunch of words should learn how to do it in pure Perl first.

I have seen recently at our job some interns knowing apparently almost everything about the Symphony framework and not being really able to write five lines of correct PHP (I even had to help them and fix their code although my knowledge of PHP is close to nothing).

With all due respect to what Your Mother and you said, I think developers should learn to do things the hard way in the language they use before using props and crutches available in packages, libraries, modules, and frameworks. Well, maybe I am wrong, after all, I must admit that don't know how the library that I use computes the sin function. Perhaps it is just me being too old school.

No worries, no offense taken :-) On a different day, I might have posted both solutions.

Coming from the perspective of learning Perl, I completely agree with you that learning the basics first is the better way to go. When I learned e.g. the Fourier transform, our professor first had us do it entirely by hand for a while, before we learned how to use the tables. The tables are of course much easier to use, but I still think it was important to know the "hard way" of doing it.

Coming from the perspective of someone Googling and looking for a quick solution to copy-and-paste, I think showing the more robust one first and making clear that it's the "better" solution is better. After all, maybe someone will implement Stack Overflow Autocomplete for Perl someday ;-)