Archive for April, 2013

My bash prompt with git/svn branch+status display

April 24, 2013

After spending a few hours last night switching between three different branches in the ack2 project, and typing “git br” over and over, I decided I needed to put branch status in my bash prompt. The only question was: Which one would I steal? Fortunately, Rob Hoelz was online and I mentioned it to him and he handed me his, so I stole it and also added Subversion support as well.

Note: Edited to fix a problem with detecting SVN branches.

#!/bin/bash

# Adapted from from https://github.com/hoelzro/bashrc/blob/master/colors.sh

function __prompt
{
    # List of color variables that bash can use
    local BLACK="[33[0;30m]"   # Black
    local DGREY="[33[1;30m]"   # Dark Gray
    local RED="[33[0;31m]"     # Red
    local LRED="[33[1;31m]"    # Light Red
    local GREEN="[33[0;32m]"   # Green
    local LGREEN="[33[1;32m]"  # Light Green
    local BROWN="[33[0;33m]"   # Brown
    local YELLOW="[33[1;33m]"  # Yellow
    local BLUE="[33[0;34m]"    # Blue
    local LBLUE="[33[1;34m]"   # Light Blue
    local PURPLE="[33[0;35m]"  # Purple
    local LPURPLE="[33[1;35m]" # Light Purple
    local CYAN="[33[0;36m]"    # Cyan
    local LCYAN="[33[1;36m]"   # Light Cyan
    local LGREY="[33[0;37m]"   # Light Gray
    local WHITE="[33[1;37m]"   # White

    local RESET="[33[0m]"      # Color reset
    local BOLD="[33[;1m]"      # Bold

    # Base prompt
    PS1="$LCYANh:$YELLOWw$LCYAN \$$RESET "

    local dirty
    local branch

    # Look for Git status
    if git status &>/dev/null; then
        if git status -uno -s | grep -q . ; then
            dirty=1
        fi
        branch=$(git branch --color=never | sed -ne 's/* //p')

    # Look for Subversion status
    else
        svn_info=$( (svn info | grep ^URL) 2>/dev/null )
        if [[ ! -z "$svn_info" ]] ; then
            branch_pattern="^URL: .*/(branch(es)?|tags)/([^/]+)"
            trunk_pattern="^URL: .*/trunk(/.*)?$"
            if [[ $svn_info =~ $branch_pattern ]]; then
                branch=${BASH_REMATCH[3]}
            elif [[ $svn_info =~ $trunk_pattern ]]; then
                branch='trunk'
            else
                branch='SVN'
            fi
            dirty=$(svn status -q)
        fi
    fi

    if [[ ! -z "$branch" ]]; then
        local status_color
        if [[ -z "$dirty" ]] ; then
            status_color=$LGREEN
        else
            status_color=$LRED
        fi
        PS1="$LCYAN($BOLD$status_color$branch$LCYAN)$RESET $PS1"
    fi
}

if [[ -z "$PROMPT_COMMAND" ]]; then
    PROMPT_COMMAND=__prompt
else
    PROMPT_COMMAND="$PROMPT_COMMAND ; __prompt"
fi
__prompt

Just drop that into your ~/.bash directory as prompt.sh, and then add

source ~/.bash/prompt.sh

to your .bashrc. Now you have color-coded branch names: red for dirty, green for clean.

ack 2.0 has been released

April 19, 2013

ack 2.0 has been released. ack is a grep-like search tool that has been optimized for searching large heterogeneous trees of source code.

ack has been around since 2005. Since then it has become very popular and is packaged by all the major Linux distributions. It is cross-platform and pure Perl, so will run on Windows easily. See the “Why ack?” page for the top ten reasons, and dozens of testimonials.

ack 2.0 has many changes from 1.x, but here are four big differences and features that long-time ack 1.x users should be aware of.

  • By default all text files are searched, not just files with types that ack recognizes. If you prefer the old ack 1.x behavior of only searching files that ack recognizes, you can use the -k/--known-types option.
  • There is a much more flexible type identification system available. You can specify a file type based on extension (.rb for Ruby), filename (Rakefile is a Ruby file), first line matching a regex (Matching /#!.+ruby/ is a Ruby file) or regex match on the filename itself.
  • Greater support for ackrc files. You can have a system-wide ackrc at /etc/ackrc, a user-specific ackrc in ~/.ackrc, and ackrc files local to your projects.
  • The -x argument tells ack to read the list of files to search from stdin, much like xargs. This lets you do things like git ls | ack -x foo and ack will search every file in the git repository, and only those files that appear in the repository.

On the horizon, we see creating a framework that will let authors create ack plugins in Perl to allow flexibility. You might create a plugin that allows searching through zip files, or reading text from an Excel spreadsheet, or a web page.

ack has always thrived on numerous contributions from the ack community, but I especially want to single out Rob Hoelz for his work over the past year or two. If it were not for Rob, ack 2.0 might never have seen the light of day, and for that I am grateful.

A final note: In the past, ack’s home page was betterthangrep.com. With the release of ack 2.0, I’ve changed to beyondgrep.com. “Beyond” feels less adversarial than “better than”, and implies moving forward as well as upward. beyondgrep.com also includes a page of other tools that go beyond the capabilities of grep when searching source code.

For long time ack users, I hope you enjoy ack 2.0 and that it makes your programming life easier and more enjoyable. If you’ve never used ack, give it a try.

When it comes to job hunting advice, question everything you’re told

April 15, 2013

Punk pioneers Stiff Little Fingers‘ signature tune “Suspect Device” admonished “Don’t believe them / Question everything you’re told.” It’s sound advice for anyone looking for guidance in the job world.

The other day on /r/GetEmployed, a user asked how he should write his resume objective for a job as a sales clerk at Bass Pro Shops. He said that the prof for his Communications in the Business Environment class told him to have an objective on his resume.

I’m guessing the prof might also have advised to put “References available upon request” at the bottom of the resume, too, which is also bad advice. I’m also guessing that the prof hasn’t created a resume in the non-educational world ever.

The key here is that the original poster of the question (the OP) didn’t ask why an objective is important. He just accepted it as true without an understanding. This is a mistake. Whenever someone gives you advice, about anything, not just jobs, ask why. Ask specifically, “Why do you say I should put an objective on the resume?” or “Why do I have to wear a suit to the interview?” You need to understand why you are doing anything, and not just follow it blindly, so that you can make a decision on if you want to follow it or not. You will get conflicting opinions on everything in life, so understand the logic behind it.

I’m guessing that if the OP had gone back to his prof and asked why to have an objective, the prof’s answer would have been not much more substantive than “because that’s just what you do”. If he were to ask me why you should not have an objective, I’d explain “because it is a waste of space that says nothing except that you want the job that you’re applying for, instead of telling good information about you and why you’re good for the job”. Based on those two reasons, the OP can make his own decision.

Note: There is a time when objectives may make sense: when you’re handing out resumes blindly, like at a job fair or something, where it’s not clear what sort of job you’re looking for. Then it makes sense. But if you’re sending in a resume for a specific job, and your objective is “to get a job that is exactly like the one I’m applying for right now”, then leave it off.

Ask questions. Understand why you’re doing what you’re doing. Don’t follow anyone’s advice blindly, including mine.