Hacker News new | ask | show | jobs
by stevebmark 3841 days ago
This is an interesting project (I'm all for approachable learning) but it seems to be missing almost every chapter...maybe not ready for the spotlight?

Bash scripting and its array of tools is a poorly designed language. Writing a non-trivial program, even for an experienced developer, is a painful process. The syntax is uneven, hard to read, and easy to get horribly wrong. I would say mastering Bash has diminishing returns past the intermediary. Any time you need to write a non-trivial program, you will save time and life expectancy from stress management by using ANY other language, even Perl or C. Writing complex shell-modifying code in my .bashrc has been one of the more tedious and non-rewarding parts of my life.

2 comments

I find shell to be a great part of my computers, ideal for making little inter-operating data-processing tools, system control programs and other hacks; it has enhanced my interaction with OS greatly. Its syntax is a little unusual, but to me it is very concise and readable. It's just that it requires some time to get used to it. After you've made your few tens-hundreds useful programs, you'll get the vibe shell has and begin to see even advantages to, say, python (in some task domains).
Maybe it's my lack of experience with Bash, but I feel the same way. While I generally find most interpreted languages easy to parse, bash just looks like Greek to me. I'd be curious to know what advantages a Bash script would have over, say, a Python script (aside from the obvious Python dependency).
I use bash pretty regularly in the devops/sysadmin world pretty often. It can do some wonders, but it has some /serious/ issues.

That said, the reason it beats Python and all is simply because it's almost guaranteed to be on any *nix server you'll log into. Solaris, BSD, some networking equipment - it'll be there. Python? Maybe. Python 2.7? Sorry, your sysadmin didn't add that yum repo and we're stuck on 2.6 at best.

You'll have similar problems if some packages aren't installed on a machine, but as long as your scripts are using the usual gnu packages, you should be good (with some exceptions of course).

It's a crappy problem to have, but it's probably not going to go away, especially in prod environments. It's just easier to run bash than to get your sysadmins to do some damn patching (or management to approve it..) than to try/potentially fail with anything else.

Then again, I'm all for using /bin/sh for everything. :)

In bash simple things are simple to write, get and read. And you don't need to deal with imports to do them, it's out of the box. Execute any ex. file? Just write down its path. Don't want to pause the main program? Add & after that path. Write output to file? Just append > filename after the command. Regex matching? Just use if [[ string =~ pattern ]]; ... lots of useful stuff, few keystrokes away. Python can do these things and more, but there is often a lot of tiresome overhead with recalling library names, dealing with local namespaces, method parameter positions, type casts just doing the most elementary stuff. This high-level complexity is useful for big and monster-big collaboration projects, but is wonderful to avoid when possible. Shell makes that often possible and is fun to use as well.
Not only just the environment dependency, but also human dependency. Being able to script in bash is considered a skill that any sysadmin would have. If you write bash scripts you can pretty much assume any sysadmin can read/write it. They may or may not know python.