Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If I'm going to be writing something that consists mostly of chaining commands together, I'm going to write a shell script, just because it gets out of my way for that purpose.

At the same time, anything I do at that level is probably going to be the exact opposite of portable: it's going to be something I intend to be specific to the exact system I'm writing for (namely, it's meant to run on a specific version of a specific Linux distribution, and possibly even to specifics of the installation on that machine). While I'm not likely to take advantage of many bash-specific features just because anything I write in shell tends to be so simple as to not need them, I'd also be an idiot to eschew useful features like arrays just because they're bash extensions.



If you don't care for portability and you need "advanced" language features like arrays and other bash-isms why do you hurt yourself by using such a terrible programing language?

In my experience shell scripts are fine for starting (and restarting) various programs and daemons or as thin wrappers around other apps. Beyond that I don't see the point. There's nothing other languages won't do better.

I've seen many "small bash scripts" grow up to thousands of lines, adding features one by one. And then you have to maintain that mess that catches fire every time an unexpected condition occurs because error handling in shell scripts is a joke.


Because there's no point in writing a Python script if more than half my code will consist of calls to commands.getstatusoutput().




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: