(The following should be prefixed with a hearty "IMHO"; this is one of those areas where you'll need to get your fingers burned a couple times to internalize when you personally are on what side of the Perl/not-Perl divide . . .)

Until you find a box still running Redhat 7.2 that's got an unpatched 5.005 that a third of the modules (or more) you need don't run on . . .

So long as you're specifically targeting bash qua bash and not "generic Bourne shell" you're not going to have enormous portability issues. With either you're probably more likely to run into cases (if you don't have a specific environment under your direct control) where just getting your tool onto the boxen in question is than exotic portability concerns. Picking the implementation language that makes it easiest to get the problem solved should be given more weight over worrying if it'll run out of the box on a late-80s era 3b2 SysV box.

(Having said that, Perl does have an advantage (to just name one, of course :) in that more is built-in to the language and you are more decoupled from environmental vagaries (e.g. does this box's stuff take strict POSIX options or GNU-y variants). But if all you need is to run 3-4 commands and glue together their inputs and outputs some form of shell might be the quicker answer; worst case you can always rewrite . . . :)

Update: Couple minor additions and tweakings of wordings.

Some links that may be of (possibly tangental) interest:

• Shell scripts and perl
• Difference between a perl script & shell script
• And extremely loosely, Re: source the license and run the program in perl (just because I like my hedgehog metaphor :)