If your shell script is just a driver for a bunch of other programs which run pretty much in order with fairly static sets of command-line options, then it can be fairly long without being an issue at all.

Right; many scripts start life exactly like that. For example, "check out some files, run make, check condition X and scp files to server Y, update config file Z...". Many lines of the script are simply using external programs like cvs, scp, mysqldump, whatever. If it's just a page full of lines like that, I wouldn't want a long sequence of system calls in a Perl script.

But as time goes by, users want more and more little bits added here and there, and even though it's still primarily a "driver for a bunch of other programs", now it's starting to do a little more error checking, more branching, and repeated bits are put into functions.

This is primarily the case I'm asking about here. When it's a sort of gray area, and you know you could just dig in and update the shell script, but you also know that it really won't fix the more inherent problems that a rewrite in Perl would. Also you want less work for yourself the next time you get a feature request for said script.

Here are a few rules of thumb I use. Your thumbs may be of a different size than mine (which would be quite probable if I was speaking literally).

I'd say any shell script that is subject to being updated as the result of a feature request is a strong candidate for rewriting in a more powerful language. Most shell scripts are part of an ad hoc implementation, a prototype of something, are fairly simple, are needed because more powerful languages aren't available (like at boot time for init scripts), or are used specifically because they can alter the environment of the login shell. If you're having to maintain changes to a shell script that's not bound to stay a shell script by circumstance then it's a good time to rewrite it.

Any time updating a program and rewriting (or refactoring) the program to be more maintainable are in the same ballpark in terms of time, opt for making it more maintainable later. This goes double if you're rewriting in a more suitable language precisely because the old language doesn't support the changes well. This goes for all languages and not just shell.

Any time a shell script is calling something written in Perl, take the time to figure out why you're calling that functionality from the command line instead of as a sub. If you have a good answer, consider not rewriting the shell script. If you don't, it's probably a good time to plan a rewrite.

If the startup times of your independent programs called by the shell script is slowing the script down too much (for some value of "too much") and you could easily duplicate most of the functionality of those utility programs in a few minutes of coding Perl, then go ahead and do most of the work in Perl and only shell out to the parts that are harder to duplicate.

If you foresee the need to run in disparate environments (like Windows and Linux) where you can choose fighting with some implementation of your shell for a nonstandard platform or just installing Perl (or using an existing Perl installation on the new target if it's there), then rewrite in Perl.

If you're having to write comments about program flow because your shell script is getting difficult to follow, then you need it to be in another, more powerful language.

If you're planning to handle more data than the command-line tools you're calling from the shell script handle well, Perl is an excellent solution.

Any situation in which your environment variables are suspect and the command-line tools you're calling change their behavior based on environment variables, you might want Perl just for the sake of things like easily checking/altering the whole $ENV hash and Taint.pm. Shell scripts that do CGI have always, for example, made me nervous.

Anything repetitive that is difficult to modularize and reuse is a sign you need a more flexible language. This is especially the case when it's because your language lacks a way to easily handle the type of conditional execution you need for the parts that aren't exactly the same.

This list isn't exhaustive, but it just might be exhausting. ;-) In any case, the best rule of thumb is probably that if you have to stop to consider rewriting a shell script in Perl, that you're going to be better off doing the rewrite.

Thanks for the excellent reply. I'll use that advice. One thing though; could you please clarify your sentence: "Any time updating a program and rewriting (or refactoring) the program to be more maintainable are in the same ballpark in terms of time, opt for making it more maintainable later."?

Edit: That is,

1. is a rewrite == making a shell script more maintainable?, and
2. do you mean, "making something more maintainable later", as in "put off making it more maintainable -- do it later", or do you mean "making something more maintainable right now for the additional changes you'll probably have to make down the road"?