I'd agree with timeless. A pile of shell-scripts is the backbone of just about any deployment. And once you have them, they're not going away soon. Beauty? Not

I'd agree with timeless. A pile of shell-scripts is the backbone of just about any deployment. And once you have them, they're not going away soon. Beauty? Not so much. Bash scripts are still the go-to solution because it's so quick to throw one together. Just paste what you have just tested on the CLI, add a few conditionals, done. Unfortunately the "done"-part more often than not drags out much further than we'd like. Suddenly there's a need to inspect the output of a process rather than just the return code. Suddenly the script should run from cron, but only one instance at a time please. Welcome to the not-so-beautiful world of lockfiles and the never-quite-complete shell environment in cron. This is the way our quick and beautiful 5-liners tend to turn into fragile 50-liners in short order. Little helpers like ftsh[1] can mitigate the mess somewhat. However, I for one try to use Python or Ruby for just about everything nowadays. It takes a bit longer to get off the ground that way - but it saves my slightly older self so much time and headache... [1] http://www.cse.nd.edu/~ccl/software/ftsh/ http://www.cse.nd.edu/~ccl/software/ftsh/