
The Shell Hater's Handbook (2010) [video] - mmphosis
http://confreaks.tv/videos/gogaruco2010-the-shell-hater-s-handbook
======
jwhite
I spent many years avoiding shell, in large part because all the arbitrary-
looking syntax and features (like quoting rules) the speaker highlights make
it frustrating and difficult to master, and I felt like it was a treacherous
enemy to be overcome through desperate struggle, rather than a tool and ally
to rely on. I know some people thrive on mastering complex and intricate
rules, but that's not my forte. I do better with overarching principles and a
unified set of orthogonal constructs, such as C (ok, debatable, but compare to
C++), Lisp, Python or Haskell.

It took a lot of pushing from a mentor for me to finally click with the
overarching principles of shell and see how to master it and become productive
with it. He really forced me into it as well, I wasn't a willing pupil for
quite some time, but he kept persisting and finally I started listening to
him. I'm so glad I did. I've never read any book or tutorial or guide that
teaches what he taught me either, despite searching several times. Also, I
don't think I could have learned to master shell if I hadn't learned
functional programming first. The day I realised how amenable shell is to
higher-order thinking was a real epiphany.

These days shell is a really important tool in my toolkit, and I can see just
how much some of my colleagues are held back by not knowing it.

Anyway, I really enjoyed the video, it was a nice exposition.

~~~
coldtea
> _These days shell is a really important tool in my toolkit, and I can see
> just how much some of my colleagues are held back by not knowing it._

Perhaps, but the shell is still a badly accrued (more than designed) set of
options.

~~~
jwhite
Yes, totally agree. But it offers something different to say Python, as the
video points out. Some things are more compact in shell than in Python,
because it's not the same sort of programming language as Python. And I reach
for Python as well, when it's the right tool.

~~~
coldtea
True. I'm not against a DSL for working with CLI programs, pipes, output
streams, processes, etc. Just that the shell as we know it is not the optimal
(or even close to optimal) example of that.

Something like ZSH and the modern Fish shell showed how much traditional
shells can improve, but we also need some better primitives, and more
controlled experience.

Oh, and they should NOT be based on emulating 40+ year old teletypes anymore,
except as part of a "legacy" mode.

~~~
catdog
Totally agree, the concept is nice and really useful but its implementation is
for a large part really a big pile of fragile and confusing hacks. Most of the
power comes of powerful tools like find, sed, awk (being a programming
language on its own), etc. The language gluing them together is nicely compact
but apart from that very disappointing. Also the everything is a string
approach has its limitations. A python script may sometimes be longer but a
lot less riddled with annoying corner cases.

------
nlawalker
This[1] Stack Overflow question sums up everything I dislike about shell
scripting. Not only does it highlight the finnicky string-oriented nature of
it, but the answers...

Multiple contradictory answers, disagreement, sub-sub-sub explanations,
historical context, caveats, workarounds, hypothetical scenarios, portability,
personal taste, different versions and implementations all show up. One
answerer felt the need to include a _footnote_.

It's like the opposite of Python's "there's one right way to do it": There are
50 right ways to do it, all of which are wrong in some case or another,
potentially depending on which way the wind is blowing.

All in regards to _checking for an empty string_.

[1] [http://unix.stackexchange.com/questions/136628/bash-
script-x...](http://unix.stackexchange.com/questions/136628/bash-script-x1-x)

~~~
unknown2374
Not to start a war, but Python's "there's one right way to do it" is nothing
more than an ambitious claim with little ground. Maybe it applies for doing
something brainless like printing a string, but the claim completely falls
apart when trying to do something as simple as list indexing/slicing or even
iteration. I'm not condemning Python in anyway, I am a fan of the latter
mention features, but that "zen" of Python is not applicable.

~~~
wwweston
> Python's "there's one right way to do it" is nothing more than an ambitious
> claim with little ground.

Probably better described as an _ideal_ , not always lived up to, but serves
as a guiding principle...

------
unixhero
So... He was ... Bashing bash?,

I for one like my shells dirty with hidden corners and black magic. Name
anywhere where you do not have bash available; embedded, grub, rescue boot
shells. I don't do embedded. Never will.

But on a serious note, does anyone know a good resource where I can pick up a
better la guage and never have to bash script again? I love writing it. It I
am sooo restricted by it, yet keep solving problems with it and also making
good money like last night. Maybe Python is the way?

~~~
sethrin
I'm familiar enough with Bash to have written an opinionated but more-or-less
comprehensive guide to it. I think Bash should be avoided as much as possible.
Bash is great for things that you would have had to type out anyway, but using
it to write programs is foolish. My rule of thumb has become, "if it's more
than 30 lines long, or if it uses more than two variables, it should be
written in another language". That said, I'm in the process of learning how to
do that myself.

Python is definitely a capable language for scripting, but I would also point
out that Homebrew is built on Ruby and uses that to great effect. You might
also check out this article on scripting with Ruby:

[http://radek.io/2015/07/13/ruby-scripting/](http://radek.io/2015/07/13/ruby-
scripting/)

And if anyone else has any tips on this subject please do pass them along.

~~~
jwhite
I appreciate your point, but I think the choice to write all or parts of an
application in shell depends a lot on what you need to achieve. Writing 100
lines of shell to glue parts of your application together may be the best way
to ship something today, even if you plan to replace that with another
language in 3 or 6 months time.

Would you care to give a link to your guide? I'd be interested to read it.

~~~
sethrin
With a few caveats:

* It's a work in progress and a bit lacking in visual presentation at the moment

* The target audience is the novice developer

* I am writing from my own experience and I am not an expert

* "comprehensive guide" should probably have been "comprehensive primer". This is what I think beginning devs should know about the shell.

[https://tenebrousedge.github.io/shell_guide/shell_guide.html](https://tenebrousedge.github.io/shell_guide/shell_guide.html)

Commentary, contributions, and criticism are invited.

As far as 'shipping something today' is concerned, that's what keeps me from
learning vim. At the moment I'm both working and going to school full-time, so
I feel like I can't _quite_ justify the time investment, but I know I'm
holding myself back from being a far more effective programmer.

I also have an acquaintance doing computational biology for whom Bash is an
essential part of his toolkit for DNA analysis. Bash sometimes is the right
tool for the job. It excels at text processing. It's just archaic and ugly,
and we have nicer options available for programming languages.

(and now that my SO is up I think I'll watch this video)

~~~
jwhite
Thank you. Looks like you've packed a lot of good stuff in there already.

I only skimmed so far, but this quote stuck out:

"Programming is fundamentally a way to save human labor, and that includes our
own labor."

I'm continually amazed at how many software engineers seem to miss this point.

~~~
sethrin
Yes, that line came out of arguments with greybeards about the problems of the
younger generation and using all these fancy frameworks and wasting memory and
CPU cycles.

I will also add the further caveat for anyone else who arrives here that this
was written in stolen hours in the last two weeks, and specifically because
the page of 'Assumed Knowledge' referred to in the introduction seems to have
been the only instruction in the shell given at Epicodus' Intro to
Programming. I'll never love Bash as a programming language, but given that
it's a tool developers use every day, I do think there's a certain minimum
amount of knowledge required to use it well.

------
the_cat_kittles
the resource that he made has been moved to
[http://shellhaters.org/](http://shellhaters.org/)

------
vram22
Reading this thread and the discussion of the pros and cons of the shell,
reminded me of this:

The Bentley-Knuth problem and solutions:

[https://jugad2.blogspot.in/2012/07/the-bentley-knuth-
problem...](https://jugad2.blogspot.in/2012/07/the-bentley-knuth-problem-and-
solutions.html)

It is about an interesting programming problem to do with text processing -
involving finding word frequencies (apparently initially posed by Jon Bentley
to Donald Knuth).

The above post (on my blog) has two solutions by me, in Python and shell, and
links to the original discussion on another blog, where I first read about the
problem - which was an interesting read, with many comments:

More shell, less egg:

[http://www.leancrew.com/all-this/2011/12/more-shell-less-
egg...](http://www.leancrew.com/all-this/2011/12/more-shell-less-egg/)

------
arca_vorago
Inevitably when shell programming is mentioned, particularly bash, I hear
quite a few devs/programmers talk about how "shell is bad and you shouldn't
use it" maybe with an added "for anything not a one-off or over 20 lines"...

I completely disagree. As the sysadmin who has been the guy actually managing
devs/programmers messes in prod, shell is the one thing that just works, is
easily readable, is easily documented, is fairly easy to write, and generally
keeps me from pulling my hair out or become violent with the devs.

Take it from the guy who actually has to wrangle all your strange
python/perl/go/node... bullshit, shell is something you shouldn't be bashing.

~~~
wwweston
> shell is something you shouldn't be bashing.

But apparently, bash is something you should be s(h)elling.

------
jwilk
Don't use "[ ... -a ... ]". It's not portable and has unclear semantics.

------
m-j-fox
[https://youtu.be/olH-9b3VJfs](https://youtu.be/olH-9b3VJfs)

------
jwilk
So where's the actual handbook?

------
miobrien
Funny presenter.

