Re: Perl converters

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

Comment on Re: Perl converters

Replies are listed 'Best First'.
Re^2: Perl converters by Theo (Priest) on Jun 21, 2004 at 02:11 UTC
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]
Re^3: Perl converters by CountZero (Bishop) on Jun 21, 2004 at 16:17 UTC
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]