

Common Bash Pitfalls - dunk010
http://mywiki.wooledge.org/BashPitfalls

======
10ren
It's the problem of nested DSLs (sed, tr, globing, bash's own control commands
etc): you need to quote (escape) each DSL's meta-characters like crazy.

It's a scary, horrific nightmare. Sure, you can learn all the intricacies, but
what a waste of your cognition! There must be a way to do it with clean
abstractions (assuming the unrealistic liberty to redesign all unix commands).
But... I have a suspicion that the horror is intrinsic to the problem, and
bash strikes a legitimate trade-off between brevity and safety. It would take
some work to be sure about this.

~~~
gloob
Based on no evidence whatsoever, my gut tells me that trying to set up a tidy
system of abstractions to clean up the problem would produce something closer
to a programming language than a shell language. On the other hand, it's
possible that exposure to *nix has simply impoverished my imagination when it
comes to things like this.

------
nas
The quoting rules in the Plan 9 shell rc are much saner. Bourne and C shell
quoting rules are a recipe for trouble. Sloppiness (e.g. leaving out quotes,
using the wrong kind of quotes) works about 99% of the time which leads you to
think your code is correct.

The big difference is that rc does not expand the result of variable
expansion. I've been planning to write a rc derivative that had job control
for a long time now. So far, I've never had enough spare time.

------
WilliamLP
Is Bash scripting still relevant today, other than working with and
understanding legacy code? Why wouldn't I use something like Python or even
Perl instead?

~~~
CrLf
Shell scripting is as relevant as it ever was.

Python or perl scripts are fine if you are doing more complex and
"algorithmic" stuff, but for automating system administration tasks, I often
find that shell scripts are simpler and more concise.

But shell scripting isn't just "scripting" (as in ".sh" files with commands).
A proficient unix user/sysadmin will often build one-shot commands using
features other people thing are only useful in batch scripts. Actually this is
something I find baffles both the Windows-types and the people that solve
every problem with "perl -e".

~~~
nailer
You're right about people needing to understand bash and Unix commands - I've
seen two 20+ line Perl scripts that run the equivalent of 'date -I' and 'nc'
respectively.

That said, I believe bash is somewhat limited for system administration -
which I know is very odd amongst system administrators - but please let me
explain why.

Using the shell on a Linux based OS in 2009, you miss out on:

* filesystem events (inotify)

* hardware events (dbus)

* config for programs with tree structured configuration (lxml)

* config for programs with sqlite based configuration

* RPM / yum beyond what their command line apps expose (and perhaps dpkg/apt too, but I need to investigate this further).

...as the commands / shell function libraries to handle these are often
immature compared to the equivalent APIs. As a result, you get sysadmins
causing unnecessary load by polling a file repeatedly at intervals (eg, via a
cron job) rather than letting the kernel tell them when their file has
changed.

I'm hopefully giving a talk about using richer languages for system
administration at PyCon 2010 - I'd love to hear any thoughts or opinions on
these matters fron HN readers.

------
jriddycuz
Thanks for this post. I'm new to doing bash scripting and this is very
helpful.

~~~
dunk010
I've got the O'Reilly bash book, it's well worth getting.

~~~
fungi
the only university text book i've held on to.

------
barrkel
The only one I didn't know about is the problem with:

    
    
         echo "hello world!"
    

I'm surprised history expansion could reach inside the quotes.

~~~
mqt
You need to use single quotes. !, $, `, \ are expanded inside of double
quotes.

~~~
barrkel
I know about variable and command substitution and escaping, it makes sense
that those expand inside " but not ' - but history expansion, something
seemingly inherent to the interactive REPL, seems out of place here.

~~~
blasdel
There is no difference between a script and the REPL.

Besides, you'd expect variables to be expanded inside normal strings -- why
special-case the other expansions?

~~~
barrkel
I'd expect them to be handled in the same "phase" as alias expansions. See
here for one example of hackery with aliases, that take advantage of their
different expansion phase:

<http://www.chiark.greenend.org.uk/~sgtatham/aliases.html>

------
ilyak
Most of those aren't specific to bash.

~~~
hernan7
Correct -- many of these are also problems in Bourne or Korn shell.

I guess by virtue of being the default shell on most Linux distros, "bash" is
now seen as a synonym to "Unix shell programming".

~~~
imd
I see it more as: people who have problems while working with Bash will go to
the Bash wiki, even if the mistake they're making could be made in other
shells.

~~~
hernan7
That's probably the case. Also, all of them being supersets of the Bourne
shell doesn't help either.

