Bash Academy(bash.academy) |
Bash Academy(bash.academy) |
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.
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.
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.
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. :)
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.
So yes, can anyone provide such a list please?
I use a lot of bash though.
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 did not realize dash was bourne compatible. Also, I'm curious what systems you've used didn't have bash installed by default, as I haven't used anything in a long long time that didn't have bash.
By default I write Bourne, and if I need the extra complexity/speed/etc i'll switch to Bash, but it's pretty rare that I need to use Bashisms.
alias '..=cd ..'
alias '~=cd "$HOME"'That would be welcome.
And you've guessed wrong about my wanting to switch to eshell.el: I took a fairly long look at eshell.el, but adopted shell.el instead. After about 5 years of using shell.el, I wrote my own mode for running and capturing the output of command lines, which I have been happily using for the last 9 months.
Like shell.el, my mode relies on a traditional shell like bash or rc to parse the command lines entered into it.
Although I do want to learn how to use Emacs Lisp code to parse the command lines I write, when I do, I'll probably just turn most of those parse trees right back into command lines (i.e., strings) and pass them to rc, bash or dash.
Once I have the ability to quickly modify my Emacs to intercept the occasional command line before it is passed to a traditional shell, in other words, I will probably feel like I have all the control I need over my relationship with the somewhat unruly beast that is the traditional Unix shell and will not feel the need or desire for the code I wrote to actually stop sending command lines to it. I'm not one for making larger changes to my software environment than necessary.
If I could figure out which of the over 13,600 lines of code that is eshell.el is responsible for parsing command lines, I'd use that, but my experience with eshell.el leads me to believe that it will probably be quicker and easier for me just to write code from scratch.
Whoa sweet! Any chance you'll be sharing? I think a lot of my shell usage could move into that type of mode if I could configure it to use rc syntax.
PS: comint mode hacking is going moderately well :) Next up is to figure out this list of completion function in shell-mode and I think I'll be done!
Sure. Do you mind if I email it to you? I'm not using git yet, and don't want to deal with git or Github today.
My email is in my profile.