Hi
Thanks, I have thought of this. But I was wondering if there's a lazy way to bypass this method, cause then I have to find all the supported units and list in the perl code, that's not a big problem but if in the future if I add a new unit in "units", then have to add in the code also.

If you trust the quoting modules to handle everything a malicious user might throw at it, buffer overflow attempts and all the other 'ploits the devious minds must expend hundreds of hours dreaming up, go for it.

I'm not the paranoid type, but I see the ongoing arms race seemingly undampened by the millions of dollars and thousands of hours of expertise that large organisations like MS, Google, Apple et al. throw at similar problems. Am I going to trust the efforts of a lone CPAN author, given that the bad guys have only to download the module to look inside to search for weaknesses?

When the alternative is safer and actually easier, why risk it.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I have looked into some perl modules for unit conversion, the Physics::Unit is quite complete but still the "units" program is more complete, which provide around 2526 units of conversion.

Still, the "units" is the preferable choice for the application. I have seen a number of perl module make use of external command line. Aha, I think I have to read their source code and see how they wrap the code. Or is there a tutorial for this ?

AnonyMonk suggested avoiding the shell for numerous very good reasons -- some of which would likely be those I would cite: if you use the shell and the external program, you've increased complexity; likely have opened some exploitable security gaps, and added overhead for your server. Unless you think the variety of conversions done by the external program outweigh all of those, heed AM's advice.

And, in any case, be aware you're reinventing the wheel! Is there some really valid reason to create and invent/install your own wheels, gears, and interfaces when a simple search -- for "unit conversions" or even "conversions" will turn up many existing (and mostly, free) services?

And, please, read the instructions around the text-entry box. Use <p>...</p> around paragraphs; <c>...</c> around code and data. <pre> tags make your nodes hard to read or bork the rendering for some Monks.

You could sanitize the input by making sure the number is really a number -- only digits and decimal point, that kind of thing (though that's trickier than it sounds, if you want to allow commas/underscores in long numbers, scientific notation, etc.). You can make the user choose from a selection of unit types, and verify that they selected a valid one from a list (because it's trivial to circumvent browser restrictions on that kind of thing). It would also help to open a pipe to/from units (with no command-line arguments) and pass the values to it in interactive mode, where bad inputs shouldn't be as dangerous as they can be on the command line.

Or you can use one of the conversion modules suggested above. Of course, then you're counting on those modules to handle dangerous inputs properly, so you should probably still sanitize your data as much as possible.

I might also ask, will you really need every conversion that units can do? Or do you have a small set of conversions that can be encapsulated in a few dozen lines at the most? The investment in a bit of conversion code that is definitely safe, versus a security problem waiting to happen, is probably worth it.