Another good resource is http://wiki.bash-hackers.org/.
In case anyone here is interested in more reading material, I recently wrote a small book about Bash that could be helpful: https://gumroad.com/l/datascience
To make sure it didn't read like a manual, each chapter is an "adventure", where I show how to use only command line tools to answer questions such as: What's the average tip of a NYC cab driver? Is there a correlation between a country's GDP and life expectancy? etc
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.
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. :)
I don't understand why people are so opposed to bash in general when it's so powerful for how straightforward it is.
People are opposed to learning yet another tool. But here's the really funny thing about the "use a more robust language" argument: not only do they introduce more dependencies, they can introduce more bugs (due to increased complexity), and are almost always a maintenance headache. The one thing that's easy to maintain after 10 years is a shell script. Perl is a nightmare to maintain after 10 years (mostly due to the lack of good Perl programmers) and awk is just barely better.
Beyond that, I have been in many situations where standalone shell scripts make the most sense for a task and in which case bash functions have helped me organize the code such that it is both more readable and also so that I don't have to repeat sections of code multiple times within a single script.
It all comes down to personal experience and preference, I think.
Too often, I think, my task is probably sufficiently simple that it could be a nice portable obviously-a-script Bash script rather than Python/whatever.
Just because you can do something in <pet-language-name-here>, doesn't mean it's best done in <pet-language-name-here>.
How long ago was that? I switched to rc in 2001 because I was unhappy with bash, and wish I had not bothered.
If the entire world switched from bash to rc when I did, then my switching to rc would have been a minor improvement, but since of course the rest of the world did not switch, my switching to rc just made me slightly incompatible with the rest of the world, and those incompatibilities more than cancel out the relatively minor advantages of rc relative to bash.
For example, file-name completion (the tab key) in shell mode in Emacs has been programmed to use the backslash character to escape, e.g., spaces in file names (and OS X ships with files whose names contain spaces). But rc does not grok the backslashes: it uses a different convention to quote characters like spaces, and no one as far as I have been able to discover has modified shell mode to use rc's convention (and none of fish, zsh, csh, tcsh, etc, share rc's convention on quoting).
rc is different enough from bash that about a third of the time, I cannot just copy a command line from a web page and paste it into rc without manually editing the command line first. for example, the two common ways of doing command substitution in Unix shell command lines are `like this` and $(like this), but rc recognizes neither convention, and I have to change it to be `{like this}. (Being different from the way the rest of the world does things for little or no actual benefit, by the way, is common in software from Plan 9.)
More examples at https://news.ycombinator.com/item?id=7614694.
When I say that rc has only minor advantages over bash, I mean that I still find it almost as annoying to write anything involving a looping or a branching construct in rc as I do in bash. And I still miss not having access to the data structures I have access to in, e.g., Emacs Lisp. And for those data structures, such as the string, that rc and bash do have, I miss the API I have access to Emacs Lisp.
I still use rc as my interactive shell (mainly because I do not yet want to rewrite my 570 lines of customizations -- mostly rc functions that wrap commonly used commands like ls and du) but plan to phase out my reliance on rc gradually over the next few years.
It's quoting is it's power!
And I fixed shell-mode in emacs for myself with the following:
https://github.com/codemac/config/blob/master/emacs.d/boot.o...
The remaining function to fix is comint-quote-filename - of which you'll see commented out there. It's slightly different from the shell-quote-command override in that it needs to only be enabled during shell-mode and it needs to know when to skip quoting all together.
Don't fear, I'll try to get it working and send it to you (and on my github). I truly enjoy rc and emacs simultaneously, so hopefully any discoveries I make can help you if you'd like them. If not - it sounds like you want to switch to eshell anyways, which could be great (albeit will have bad things as well as it doesn't support i/o redirection).
Is this the Tom Duff of Duff's Device fame?
I for one am enjoying reading through the informative guide.
Nice job on the author for deploying Prose.io for community editing of the guide.
