"Chris Devers" <[EMAIL PROTECTED]> wrote:
On Fri, 29 Oct 2004, Thomas Bätzler wrote: Chris Devers <[EMAIL PROTECTED]> claimed: [...] > well written shell scripts don't need Perl and well written Perl > scripts don't need external shell commands.
I think that's the "ivory tower" point of view. Down here in the trenches, it's more like "a well-written Perl script uses shell commands where it makes sense". Obviously the art is in knowing where it makes sense and where not.
[...]
Likewise, shell scripts with lines like this:
grep 'foo' logfile \ | perl -pe '$l=$_; ($s=$l) =~ m/^([0-9])+/; print scalar localtime $s, " ";' \ | sed -e 's#\( 200[0-9]\) 1[0-9]*#\1#' -e 's#\(.*\)# <li>\1</li>#' \ >> $htmllog
Are complex enough that it's probably worth considering rewriting the whole thing in Perl. Perl is a much bigger program than most of the standard shell tools, so a script like this is probably slower than it needs to be.
One might argue that using sed as a filter for a Perl program is dubious - after all, you already have the line you're interested in, so why not do it all in Perl. On the other hand, it's probably a command line that was plugged together on the fly, to do just one job.
In one point you're wrong, though - for selecting lines from a file and mangling them into another format, a hybrid of shell grep and perl is actually much faster than a pure Perl implementation - from personal experience I'd say 1.5 to 2 times on a single CPU system. If you're on a SMP box, probably even faster. This is no doubt because grep uses a simpler pattern matching algorithm, and also because it's much more efficient on I/O.
Moreover, to get this down to a reasonable line length, it uses an obtuse style that would really be more readable as a Perl script
opaque? In any case, it looks like the person who wrote the code was not very proficient in Perl. Otherwise (s)he's used something like
perl -pe 's/^(\d+)/localtime $1/e'
to turn time_t timestamps to human-readable dates ;-)
spread out over several more lines. In the long run, the pure Perl version would be easier to maintain, even if in the short term it seems more expedient to kludge in a tricky bit in the shell script using a single call to Perl, then reverting to shell tools afterwards.
Well, I wouldn't argue with the value of setting up proper scripts that ones colleagues can use, too. Throw in a bit of Getopt::* and things get downright luxurious ;-) Still, it's not Perl for Perl's sake, so if I can be more efficient by tying in other tools, I do that. And obviously Perl was meant for stuff like that.
What's expedient isn't always a good idea in the long term.
Who could argue with that ;-)
Thomas
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
