| [reply] |
Thanks, I will look these references up.
| [reply] |
| [reply] |
If you look up the FAQ you will note it is not optimistic about the benefits. If your shell scripts work why not leave them. If you want to convert them to perl it is a good oportunity to learn about the language with some useful small widgets.
| [reply] |
As the faq indicates, you probably gain neither speed nor resources by a machine-translation.Rather you should ask yourself what your scripts do and see if there are any benefits to recode them in Perl (or any other language for that matter). Of course if your intended goal is simply to learn Perl, then studying machine-translations of shellscripts into Perl is probably not the way to go. Such automated translations will have little or no "educational value". Either they are simple one-on-one translations which will not show the strength of the language, or they will be so highly optimised as to be virtually unreadable in all but the simplest of cases. Far better to buy a good book on programming and start coding away. Hanging out on PerlMonks wont be bad either!
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply] |
I know of one case where a badly written (that's probably the reason) shell script was replaced by a Perl script with a speed gain of a factor of 1275. Not per cent! YMMV
-Theo-
(so many nodes and so little time ... )
| [reply] |
If your shell script uses a lot of "expensive" external commands, may be even in a loop and you can replace that by some internal commands of Perl, the speed gain would be enormous. However, if you "machine translate" such script into Perl by calling exactly the same external commands (through backticks or system), you will be worse off than before.
CountZero "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law
| [reply]
[d/l] |
