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.
I was trying to be specific there. I'm not saying that it's never legitimate for a Perl script to run a system( ... ) call or execute something in `backticks`. Everything has a place, including those tools. I'm specifically talking about things like this in Perl: @files = `ls -1`; $timestamp = `date`; Constructs like this can easily be done in pure Perl. 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. 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 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. What's expedient isn't always a good idea in the long term. -- Chris Devers
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
