Bash habits I need to break and habits I need to make.

22 01 2011

I got started with Linux back in the summer of a 1999 while a friend and I messed around with Turbo Linux, Red Hat 6.0 (5.2? maybe? Can’t remember exactly), and Mandrake 6.0. I stumbled around quite a bit on the shell and the GUI was no where near as good as it is now. One day while at the bookstore I saw that they had a great deal on computer books. A few of them caught my eye and so I bought them. One of the books was Unix Shells By Example 2nd ed authored by Ellie Quigley. It is hard to explain the history that I have with this book.

First, I can’t believe that I have owned this book for over 10 years, though it does show. Some pages are practically falling out (just barely hanging on), the spine has been broken, and when you set the spine on the table and let the pages fall open the book opens straight up on dealing with arithmatic in bash using exec (a particular task I had years ago where I had to do complex math to pass parameters to a scientific computationally hungry cluster and the book was in use all day every day and I only ever turned a few pages back and forth).

Next, it shows that I have gotten FAR more use out of this book then the $40 I spent on it all of those years ago. Probably one of the top 5 purchases of my life.

Lastly, it is a reminder that at the ripe old age of 28 I am not far from yelling at kids to get off my virtual lawn…seriously. I mean I cut my teeth on versions of bash shell around the release of bash 2.0 using Linux kernels 2.0-2.2. Over the years I can and have done some things using bash scripts that hardcore programmers wished they could do in their compiled language of choice. An example is that large cluster of computers doing very complex math and all interacting with each other over ssh (using keys). It took over three years before the C++ programmers could get the overall performance that I had using bash scripts.

Sure, I have sorta kept up with things as the years have gone on. Dave Taylor has my favorite articles every month in the Linux Journal. However, I hadn’t quite realized how far behind I had fallen. This month at my Linux Users Group, one of the guys was talking about how he was so exited that Debian (a favorite distro for both of us) was going to have bash 4.0+ in their squeeze release. So? It is a Bash shell. What can they possibly do to get excited about?

So I went and read a TON of information on Bash 4.0. Which then branched out into a ton of other stuff that they have done that I have some how missed. I guess it showed me that even on things I thought I knew inside and out, if I don’t keep up with the changes I get left behind. I have compiled a list of things that I am going to start working on to improve my shell scripting abilities even more. I think I may have to finally retire my Unix Shells book. If you have a suggestion on a newer shell scripts book that you think will last me another 10+ years, please let me know in the comments.


PS: Another sign of me getting close to yelling at kids to get off my virtual lawn. A guy at work was talking about a problem with his new laptop and Ubuntu. He complained “Then [the guy on the forum] told me to try out the patch. When I asked him how I was supposed to do that he told me that it was simple kernel recompile! Like I am the type who is going to recompile a kernel! Sheesh. Who does that anymore?”
Someone who considers himself a computer geek and Linux savvy and not only has he never compliled a kernel, but considers it a task too detailed and difficult to do.
*deep breath* *siiiiiiiiigh*

Links to sites where I got a lot of this information. Please note that I have been bumming around the web for a few hours now and I didn’t keep all of the links I visited. These are just the ones I wanted to keep around for future reference.

Bash Hackers
Linux Tutorial Blog*
*This one is older information (2008) and mostly the same information as the others, but I like this table. I even learned an option that I didn’t know existed before.

1) Using -x to check for my errors instead of spending $hours debugging a typo…
$ /bin/bash -x ./

2) Using bash to increment for me.
# REALLY old way of incrementing
a=`expr $a + 1`
# Old way of incrementing by one.
# New way of incrementing by one.
let a++
echo $a

3) Checking strings with built in test functions.
# Old way of checking strings.
if [ "$a" == '' ]; then echo True; else echo False; fi
# Second old way of checking strings.
if [ x"$a" == 'x' ]; then echo True; else echo False; fi
# New way of checking strings.
if [[ $a = '' ]]; then echo True; else echo False; fi
# or at least do
if [ test = "$a" ]; then echo True; else echo False; fi

4) Using bash parameter expansions more often instead of passing to awk or sed.
# Old way to strip off extension.
basefile=`echo $file | sed -e 's/.pdf$//'`
# New way to strip off extension.
echo "$basefile"

More options for this can be found here:

5) Using $(cmd) instead of `cmd`.
# Old way
# New way

6) Passing stderr to a pipe
# Old way using file descriptors.
cmd_1 3>&1 1>&2 2>&3 | cmd_2
# New way.
$(cmd_1 >/dev/null) |& cmd_2

This is one that I am proud to have thought up on my own! I had been using that old method for years now (when I care more about capturing the errors then I do the output). As I read through the all the documentation I saw something that reminded me of this particular bit of nasty code. I thought about what I could do to improve it and I came up with this solution! I updated a bunch of my scripts and they are all working as the should!! 😀 I am so pleased. Then I Googled it.

Apparently I am not the only one to have come up with this solution…
Maybe next time when I come up with a great idea to reduce complex code I will actually be the first to do so… :-/

7) Matching strings with regular expressions!!*
* This Really Excites Me. Probably a bit too much which is why I am sure this will get me in trouble…
$ if [[ "This is a string" =~ ^Th.*rin. ]] ; then echo True; else echo False; fi

8 ) Totally guilty of one of the Bash Pitfalls found here:
In fact, one of my scripts had a complex function to check that things had gone right and had created the directory in which the script was about to cd into before running commands. I have been meaning to go back and clean up that nasty code for a while, but it works so why break it unless I know I have the time to fix it? I am so ashamed for not having thought of this before. I blame the stressful job at the time…
# Old way
cd /foo; bar
# New way
cd /foo && bar
# Actually in my case it became
cd /foo && $( bar -options )

9) Start using $HOME instead of ~ in scripts
# Old way
cd ~
# New way
cd $HOME

10) Greping output of PS
# Old way
ps -elf | grep [g]edit
# New way
pgrep gedit

I still have a few pages to go through so I will be adding to this later.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: