Darn it! I knew I should have posted my DON'T USE EVAL FOR THIS warning. As soon as this topic comes up, some fool (in this case delirium) comes along and tries to use eval.
Get it? Never use eval for this. {sigh}
And I wondered "Oh, maybe this time, we'll get through this without the security-hole inefficient broken eval-string solution" when I saw the first post. So, I didn't post my warning. Looks like I should have done it this time, and I'll have to do so next time. {sigh}
| [reply] |
Randal,
I have read your standard disclaimer, and it makes no reference to what you mean when you call people fools. So my question to you is: What did you mean when you called me a fool?
I can see it as nothing else other than a personal attack, which your standard disclaimer states that you never do. After re-reading your post, you are still calling me a fool.
This forum is a fun place to find multiple ways to solve coding problems, most of which shouldn't be considered production safe. I don't feel the need to defend any solutions I present to you, or to make sure they don't violate any of your pet peeves.
On the other hand, I am a curious fellow, and would like to know why eval is a bad solution in this case. I read the post you linked to, which appeared to be a warning against eval without specifics. I understand that it is inefficient, but the solution I presented was self contained, and I do not see a method by which "`rm -rf /`" or something similar could be introduced.
Eagerly awaiting your reply,
Curtis
| [reply] |
