
Bash Academy - obeid
http://www.bash.academy/
======
alexis-d
This is a WIP (hence why there are drafts and todos). This is being done by
the folks at
[http://mywiki.wooledge.org/BashGuide](http://mywiki.wooledge.org/BashGuide)
which is definitely a valuable resource if you're trying to learn Bash and its
idiosyncrasies.

Another good resource is [http://wiki.bash-hackers.org/](http://wiki.bash-
hackers.org/).

~~~
ProfDreamer
The Advanced Bash-Scripting Guide is a good resource as well:
[http://www.tldp.org/LDP/abs/html/abs-
guide.html](http://www.tldp.org/LDP/abs/html/abs-guide.html)

------
raboukhalil
The first few chapters look very good, best of luck with the rest!

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](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

~~~
triangleman
After clicking the link to your book in Firefox, it is impossible to hit the
back button to return to this page.

~~~
raboukhalil
That's really strange; it might be an issue with Gumroad, sorry about that.

------
sciurus
If you want feedback on the quality of your shells cripts, shellcheck is a
great tool. You can run it locally or use
[http://www.shellcheck.net/](http://www.shellcheck.net/)

[https://github.com/koalaman/shellcheck](https://github.com/koalaman/shellcheck)

~~~
raboukhalil
This, along with [http://explainshell.com](http://explainshell.com), are some
of my favorite Bash resources.

------
stevebmark
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.

~~~
endemic
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).

~~~
bpchaps
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. :)

------
desireco42
This is much needed. We essentially have all this software we deal with daily
and many people don't know basic things about it, not just bash or zsh... and
that is funny, people install zsh because it's the thing to do, but you see
that they don't know why.

------
digital43
It'd be cool to see some kind of interactive exercises like (Vim Interactive
Guide) [http://www.openvim.com/](http://www.openvim.com/) and (Git)
[https://try.github.io/](https://try.github.io/)

~~~
zappo2938
How about a version of VIM Adventures[1] but named instead BASH Adventures?

[1] [http://vim-adventures.com/](http://vim-adventures.com/)

------
headcanon
Thanks for making this! I wish I had a guide like this when I was starting
out. Does anyone know if there is something like this for zsh? I'd imagine
there would be a lot of similarities, but some notable differences.

~~~
digital43
This should at least give you an overview of differences among unix shells
[http://hyperpolyglot.org/unix-shells](http://hyperpolyglot.org/unix-shells)

------
peterwwillis
Bash is incredibly useful, and I think more people should use it as a cross-
platform default scripting language. That said, for the most compatible shell
scripting, learn Bourne shell scripting.
[https://en.wikipedia.org/wiki/Bourne_shell](https://en.wikipedia.org/wiki/Bourne_shell)

~~~
carlisle_
It drives me nuts when people say this. /bin/sh is not even Bourne in some
distros (dash in Debian for instance), and bash is installed everywhere
(unless you're running AIX, I think ksh is still default). There are some
bash-isms that are good things and people shouldn't be afraid of. I think it
is actually counter productive to tell people to write things in other
languages if you need more complexity. If you're writing a script I think you
should be weighing instead whether or not you should fully automate what
you're doing. If you decide that's the case of course bash isn't going to be
your go-to tool, but if you're writing a one-off script what's the point of
telling people to use a more robust language if you can do the job with bash?

I don't understand why people are so opposed to bash in general when it's so
powerful for how straightforward it is.

~~~
peterwwillis
Dash is Bourne-compatible! And Bash is _not_ installed everywhere. I can think
of at least five systems i've used in the past five years that either didn't
have Bash, or Bash was not the default shell, and even the path to Bash isn't
the same on all systems (since it is technically an add-on). Anyway, I did not
say use Bourne for more complexity, I said for more _compatibility_.

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.

~~~
carlisle_
Right I was thinking about that after I replied to your comment, that I let my
point get away from me. I read so many other comments putting down bash I was
pleading my case to them, not you, haha.

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.

~~~
peterwwillis
Solaris, BSD, HPUX, hell even stripped-down Linux installs (though sometimes
it exists and is just in a weird path). Occasionally I need to bootstrap an OS
installer and they never 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.

------
massysett
If you are writing functions in Bash, your task is probably sufficiently
complex that it would benefit from being written in a language other than
Bash.

~~~
peterwwillis
Please list other backwards-compatible interpreted languages installed by
default on dozens of operating systems and platforms spanning 26 years.

~~~
burke
Awk and perl.

I use a lot of bash though.

~~~
ChrisArgyle
About 7 years ago I had a job where we supported almost every Unix all the way
back to AT&T SVR3 (including OpenServer, UnixWare, HP-UX, AIX, Linux, OSF/1).
With the exception of SVR3 every single one had binary packages for Perl 5.

~~~
ausjke
until you run embedded routers and such, where perl is too large and
bash/ash/mush rules.

~~~
peterwwillis
Or you're bootstrapping an install process and perl isn't included, but a
shell is.

------
wickchuck
I know this is still a WIP, but I found the examples tough to read with colors
chosen. Should add does look like a fantastic resource though!

------
baby
Game doesn't work

------
mirchada776
[http://play.bash.academy/](http://play.bash.academy/) is 404

------
ausjke
[http://guide.bash.academy/03.variables.html#toc7](http://guide.bash.academy/03.variables.html#toc7)
in this page those block-diagram looks nice, how is it made? some markdown
enhancements like mermaid of plantUML?

~~~
chairleader
I've used ditaa [http://ditaa.sourceforge.net/](http://ditaa.sourceforge.net/)
for similar diagrams, and this Jekyll plugin to use it w/in Markdown
Documents:

[https://github.com/matze/jekyll-ditaa](https://github.com/matze/jekyll-ditaa)

~~~
ausjke
yes ditaa, forgot to mention that, but I don't yet know how to use ditaa etc
to make those blocks as in the bash site, it just looks nice.

------
dsugarman
In hopes that the creator does read this, it looks like a great resource but I
can't read the text, my eyes are very strained and I got a headache very
quickly.

------
codemac
Use rc instead. My life has gotten so much better since I gave up on other
shells.

[http://tobold.org/article/rc](http://tobold.org/article/rc)

[http://github.com/rakitzis/rc](http://github.com/rakitzis/rc)

~~~
hollerith
>My life has gotten so much better since I [switched to rc].

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](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.

~~~
codemac
> 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 (which are part of the base system on OS X). 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.

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...](https://github.com/codemac/config/blob/master/emacs.d/boot.org#use-
rc-escaping)

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).

~~~
hollerith
>I'll try to get it working and send it to you

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.

~~~
codemac
> 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.

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!

~~~
hollerith
>Whoa sweet! Any chance you'll be sharing?

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.

------
uxcn
I've started trying to stick to dash syntax for shell scripts.

~~~
effie
Does dash have some advantage to bash, except being faster? Doesn't it lack
some useful bash functionality?

~~~
uxcn
The main advantage is that it's a smaller dependency. If you don't need the
functionality, there's a bigger benefit to being portable. For example,
running scripts on a router with embedded linux.

------
rootkea
I wish we'll have assembly.academy someday. One of the poorly documented art
as shell.

------
renlo
The site is unusable for me because of lag from the parallax. It's always on.

------
zackify
We need the zshell academy

------
jonesb6
I... really need this.

------
iamroot
this is, for the most part, non-functional and incomplete

~~~
moviuro
yet not full of bad habits like the "defensive bash programming" blog post
that was on the front page earlier today. It's the continuation of
[http://mywiki.wooledge.org/BashGuide](http://mywiki.wooledge.org/BashGuide)

------
brianzelip
Folks, it's most likely the case that the author behind bash.academy did not
post the link to HN, so ease up on the flames.

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.

------
fazza99
please test the site before releasing it.

------
giis
Looking at the github page
[https://github.com/lhunath/bash.academy](https://github.com/lhunath/bash.academy)
Its been there for 2 years. and last commit was 3 months back.

~~~
rubiquity
Omg a whole 3 months ago???!! This repo is soooooooo stale. Bash is constantly
changing every day right? I don't want to learn from an antiquated resource!

~~~
giis
I posted above stat as response to someone telling the link is posted in HN
while the project is still in its early stage. (work-in-progress).

~~~
anonbanker
remember, kids: duration of time is the sole data point with which you should
determine what "stage" a project is at.

~~~
giis
Yes kids remember, if a project more than 2 years, don't say things like "You
posted the link, while author just getting started."

