Customizing the bash prompt

I prefer to use a bash prompt which displays both the date and time.  That makes it easier to see when commands were issued when scrolling back through the terminal's buffer.  Here's what my prompt looks like.

The bash settings for this prompt are shown below.  You can add these lines to your .bashrc file.  For operating systems which support an admin or root user, I change the prompt's background from blue to red to give quick confirmation of that elevated privilege level.

# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
PBG=44
PFG=37
TFG=36

PS1='\n\[\e]1;Term ${$} \a\e]2;\u@\h - ${PWD}\a\e[1;${PFG};${PBG}m\][\D{%m-%d} \t] eh? \[\e[m\] '

Searching for source files which contain multiple keywords

Recently I was presented with the challenge of searching for the code which built a SQL query.  I knew what the query looked like from a log file but searching for individual terms used in the query such as SELECT, FROM, or WHERE produced hundreds of matches which I didn't want to waste time checking one at a time.

So I created the following bash script to search files for each term in order.  I used ack instead of grep for the first search so it would pick only source files of interest for me.  The results from my bash script returned only a single file which contained all the terms and it was this one which I needed to modify.

if [ -z "$2" ]                       # Is parameter #1 zero length?
then
    echo "usage -- rgt term1 term2 [term3]..."
    exit 1
fi

files=`ack -l "$1"`

# shift past the first search term argument since 
# we've already used that one 
shift  

for var in "$@"
do
    files=`echo $files | xargs grep -l $var`
done

if [ -z "$files" ]; then    # are results zero length?
    echo "no matching files found"
else
    echo "matching files:"
    echo "-------------------------------------"
    echo "$files"
fi

Quick and easy code searches

Getting presented with a large and unfamiliar code base can sometimes prove daunting.  One of the biggest challenges is how to efficiently search for things when you need to make changes.

Since I'm a big fan of platform independent tools, I had been using recursive grep searches but those frequently return too many results.  It can be difficult to limit the files searched to just the source files of interest.  Perhaps you have a unit test directory you don't wish to search.  You might also want to skip directories containing library files or other binaries.  I prefer a tool called ack to help limit the unwanted files being searched.  That prevents lots of false positives which you need to wade through.

Creating a file called .ackrc in your home directory is an easy way of setting the default settings for ack.  The following sample .ackrc file configures ack to ignore a few directories which normally don't contain code of interest.  It also sets an alternate file extension for makefiles and configures the default source languages of interest.

--ignore-dir=.svn
--ignore-dir=dist
--ignore-dir=docs
--ignore-dir=examples
--ignore-dir=lib
--ignore-dir=tests
--type-add=make:ext:make
--asm
--cc
--make

Using ack and an appropriately configured .ackrc file can significantly reduce the number of lines of matches you must check when searching your source tree for a keyword.

Making code searches easier

When modifying source code I'm not familiar with, it's usually necessary to do some recursive searches to figure out what to change.  You can use a simple recursive grep but I prefer a tool called ack.  You can download ack in one of several forms.  I prefer the all-in-one perl script version.  I prefer ack because it can be configured via .rc (run command) file or command line to limit the searches to files of interest.  You can ignore files with certain extensions or entire directories.  Few things are more disheartening than searching for a term within the code only to find out it appears on many hundreds of lines.  Who feels like wading through hundreds of lines to find what you're actually looking for?
 
I also use the following bash function to pipe ack's output to gvim so I can weed out unwanted matches quickly.  This is handy if the search term is a common word which is also used as a variable or function name.  I delete lines containing any variations which aren't of interest which helps reduce the job to something more manageable.

The ack script may be replaced with a simple recursive grep if you'd like.  You can also use a different editor if you don't care for Vim/Gvim.  You'll just need an editor capable of accepting input from stdin.  The following function also tells gvim to highlight the search term which I find to be a time saver.

function    ackvr    # invoke ack perl script and edits the match
{
    if [ -z "$1" ]; then
        echo "Usage -- ackvr SearchPattern
    else
        echo "ack searching for $1"
        ack "$1" | gvim -c "/$1" -
    fi
}

Using RSS feeds to save time

I've long been a fan of RSS feeds as a way to save time when monitoring blogs.  It affords me the ability to see the headlines of new posts (and only the new posts) as they appear.  I can choose to visit the blog if the headline sounds interesting or if none of the articles catches my eye, I can mark all headlines read which makes the web site disappear in my RSS reader until the next time they add content.  It is so much faster than actually visiting a bunch of web sites that it's not funny.

I have three separate lists of RSS feeds I monitor.  I use a cross-platform app called QuiteRSS on both my Mac at home and on my Windows laptop at work.  On my phone and tablet device, I use a mobile app called Feedly to monitor a third set of RSS feeds.

At home I follow RSS feeds for beer news, book releases, and information about RetroComputing.  I don't read about these topics at work because I don't feel right about asking a company to pay me to do that.

At work I follow a number of technical RSS feeds on computer security, software development, embedded system, computer communications, and a few other tech topics.  These are all directly or indirectly related to my job.  Having these RSS feeds to read allows me to take small breaks at work while my software is building or when I'm waiting for code to download to one of my development boxes.  I'm a firm believe in the studies that say these micro-breaks improve productivity.

Whenever I have a bit of downtime during the day such as while waiting at an appointment or in line at a store, I can look at the local news sites I monitor in the Feedly app on my phone.  Feedly synchronizes feeds so when I look at those same feeds at home on my tablet device, I only see articles I haven't marked read on either device.

Preventing strange colors for the "ls" command

I occasionally need to connect to a Linux server via ssh.  Since I use an ssh client which has a dark background, the default colors used by the ls command frequently makes directory listings difficult to read.  Fortunately you can solve this one of two ways.


For a solution which will persist throughout the ssh session, you can issue the "unalias ls" command.  That removes the alias which causes the odd coloration.  It will reappear the next time you log into that server.


For a non-persistent solution you can preface the ls command with a backslash.  Using "\ls" prevents any command alias from being used.

Using Vim's folding feature to hide inactive conditional code

I was recently looking at some C code which had lots of conditionally compiled sections (#if, #else, #endif).  I don't care for code like that but sometimes it's a necessity when source code must support multiple hardware platforms.  In any case, it makes the code harder to read.  So I've whipped up a little macro which if placed on the #if or #else line, will use Vim's folding feature to hide that portion of code.


map    \fc   mx^%:'x,. fold


To unhide the folded section, you can issue the zd command.  I've buried that in a macro invoked by "\fd" since the more mnemonic macros are easier for me to remember.