The same reason we don't recommend regular expressions for parsing HTML.
To me, this is quite different.
The OP has an internal variable containing a (CSV) string and wants to quote the fields. It is really not like processing an HTML or XML external file, it is a variable within the program. The OP presumably knows how the string was generated and should presumably be sure of its content.
The string was probably generated within the program. And even if coming from some external source, hopefully the string has been verified and possibly untainted, maybe sanitized, whatever is needed to be reasonably sure of the content. If the string is coming from outside the program and not generated by the OP, these checks are necessary anyway.
Please note that I did not object to use the modules mentioned by haukex, quite to the contrary, but only to the advise "do not to try to quote the strings yourself". I believe that there are many cases where you know exactly what your data is like and where you really can quote the strings yourself. Sometimes, you don't need heavy artillery when a fly-swatter will do the job.
| [reply] |
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
| [reply]
[d/l] |
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;
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;
| [reply]
[d/l]
[select] |
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.
| [reply]
[d/l]
[select] |
