Shell scripts and perl

[sg]

Under what conditions and/or for what goals (if any!) would a shell script (csh, bash, dos-batch etc.) be more appropriate than a perl script?

Update (Sep 29, 07): People have been wondering if this is a homework question: it isn't. Recently, my hard-drive crashed and I am working on a periodic data archival scheme using rsync and cdrtools. I have been successfully rsync'ing by hand. Since the planned automated script would be calling rsync and cdrtools -- which in turn would be interacting with the OS to work with the file-system -- I was wondering if it would be safer to stay close to the OS and use batch files rather than perl. Such is the motivation for this question.

[Fletch]

When it's easier to write the shell script than the Perl version, for whatever value of "easier" passes your particular threshold. And it's going to be really, really subjective exactly what the threshold is from person to person and shell to shell.

Just as an example, where someone else might whip out File::Find (or File::Find::Rule) I might be just as likely to knock out a zsh one-liner right at my prompt since I've gotten fairly comfortable with it's pretty rich recursive globbing syntax. But then there's other stuff like moderately fancy CSV file manipulation that a better shell head might easily do with some arcane paste invocation that I'd break out Text::CSV_XS for.

If you're looking for generalities you'll likely get some pointers as to general areas of competency (like a shell's going to be better at chaining pipelines of commands together, where you'd be knee deep in system or open3 calls in Perl), but to know where it's going to be more appropriate for you you'll need to learn your tools and get comfortable enough that you know where your boundary lines are.

[Corion]

Are this and "write once, run anywhere" homework questions?

Anyway. A shell script is better suited to the task than a Perl script for example if the whole process is just a single pipe in which the data flows. The following shell script is what I consider borderline:

#!/usr/bin/ksh
ZR=$1

./dump_abrechnungssatz.pl --delimiter ";" --columns COL1,COL2,COL5 ../
+INPUT/FOO/X06*$ZR*[0-9].gz \
  | grep -v ";[+]0000000000000,000000" \
  | grep -v ";1;" \
  | cut -d ";" -f 1,2,3 \
  | sort -u \
  >../OUTPUT/FOO_bn_kst_$ZR.csv

[andreas1234567]

I prefer shell scripts to Perl for tasks that:
• Are small and simple.
• Are unlikely to fail. (I find pipeline error handling difficult: grep '\.pl$' foo | sort | uniq | xargs find. Now exactly where is the error? )
• I find hard write in Perl (e.g. find /usr/ -maxdepth 2).
Otherwise I find myself writing Perl.

[Fletch]

(Drifting slightly offtopic, but . . . :)

Are unlikely to fail. (I find pipeline error handling difficult: grep '\.pl$' foo | sort | uniq | xargs find. Now exactly where is the error? )

zsh provides a pipestatus variable which is an array of the exit statusen from each component of the last pipeline. Granted that doesn't solve problems where one part of the pipe is generating bad data, but it does let you handle a few more kinds of problems.

Update: Oop, quite right. Recent bash have stolen :) this zsh functionality (along with programmable completions and other Z goodies :).

[tcf03]

bash provides this as well.

[moritz]

A typical textbook (and quite valid answer) is "when perl is not available on the target platform/maschine".

[dwm042]

A statically compiled shell (such as /sbin/sh) is strongly advised for start up scripts and any work on any server where /usr will not be mounted (i.e. single user mode on servers with a separate /usr). Otherwise, if the problem is small, can be equally well written in shell as Perl, and fits on one page, shell is entirely adequate.

Update: clarification.

[swampyankee]

One obvious condition is when one needs to have a script that does the same thing on multiple operating systems. After all, Windows, *ix, z/OS, VMS, etc all have different scripting languages.

The other condition is, of course, when it's easier to write the script in Perl, which is why I learned Perl, as opposed to trying to write something with significant logic in a BAT file.

[blazar]

Hence the famous quote of $Larry's: "it's easier to port a shell than a shell script."

Also see e.g. Difference between a perl script & shell script.

[bruceb3]

The only reason that I have seen that sticks, is when the majority of the team only knows shell programming, so it becomes and issue of maintenance. Obviously I am not referring to a team of programmers.

[apl]

<Exageration>Never!</Exageration>

The syntax for bash (used on one Unix box at work) is slightly different than the syntax in ksh (used on another Unix box at work) which is greatly different than the OS syntax on the piece of Big Iron I work on.

Rather than having to check the subtle differences that inevitablty (for me) result in errors, I write the script in Perl.

[rah]

That does sound like homework!

Since you mention various shells and BAT files in the same sentence I'll throw this out there. If you need to run on Windows and UNIX, perl (or ruby, or python) may be the only way to go. While it can be tough to make certain it remains portable, there's not much hope in writing anything cross platform in any shell language.

The other comment I'd include is if any modules are required. If any/many CPAN modules are required to write it in perl, it may be easier to use shell.

If a valid goal is learning, why not write it in both. If you are familar with shell scripts and learning perl write what you know and learn by porting.

Finally, what usually carries the day - in which can you do it faster! Right or wrong, that usually decides the issue for me.