June 2010 Archives

To scratch a few itches that I had, I wrote a number of bash functions.  These are published on Github at http://github.com/cxreg/smartcd

This repository is made of 3 components, each of which are separately useful:

  • bash_arrays
  • bash_varstash
  • bash_smartcd
And with their powers combined, you can.. well let's not get ahead of ourselves.


Bash is a very featureful shell.  It has things that many people aren't even aware of.  One such feature, added in 2.0, is the ability for shell variables to be real arrays, instead of just strings.  Using string variables and IFS (Internal Field Separator, if you don't know, don't ask) to manage multiple values can be very frustrating.

You can initialize array variables with the syntax "name=(value1 ... valuen)", and assign individual elements like "name[subscript]=value".  You access them by index like "${name[subscript]}"

$ foo=(bar baz biff)
$ echo ${foo[2]}
$ foo[3]=blah
$ echo ${foo[3]}

$ foo[3]=blah
$ echo ${foo[3]}

However, this syntax is pretty awkward, and almost no convenience functions are supplied.  If you've worked with any high level dynamic languages, you'll be familiar with things such as push, pop, shift, unshift, and reverse.

These missing functions are provided by the included file bash_arrays, and are named
  • apush - add an element to the end of the array
  • apop - remove an element from the end of the array
  • ashift - remove an element from the beginning of the array
  • aunshift - add an element to the beginning of the array
  • areverse - reorder the array backwards
along with a few others
  • afirst - print the first element but leave it in place
  • alast - print the last element but leave it in place
  • alen - print the number of elements in the array
The "a*" naming convention is to indicate that they work on arrays, and to avoid possible naming conflicts with other functions that might use such common words.

Example usage:

$ apush foo bar baz biff
$ alen foo
$ apop foo
$ apop foo
$ apop foo

Unfortunately, there isn't a simple way to both modify a shell variable and "return" a value. The only way to capture a non-numeric return value is by executing a sub-shell, which will modify the value only in the sub-shell.  The modification is of course lost when that shell exits.

bar=$(apop foo) # $bar has a value, but $foo is unmodified!

To work around this shortcoming, the mutators (functions which modify the array) that also need to return a value (apop and ashift) set a variable which contains the returned value, $_apop_return and $_ashift_return respectively.

apop foo >/dev/null # run in current shell, and quiet output


This file provides 2 functions, stash and unstashstash stores the value of a variable to a temporary location.  unstash restores its value from the temporary variable and deletes it.  The name of the temporary variable is derived from the current working directory of the shell, which means you'll need to be in the directory you stashed from to unstash properly.

$ export FOO=bar
$ echo $FOO
$ stash FOO
$ export FOO=baz
$ echo $FOO
$ unstash FOO
$ echo $FOO

While this might sound a bit arcane, it is specifically useful with...


This file provides a replacement for cd.  It runs the specially named ".bash_enter" shell script when it enters a directory, and runs ".bash_leave" when it moves away, using the bash_arrays functions to keep track of things.

Once loaded, it's enabled by simply adding

alias cd=smartcd

to your shell initialization file.  All path differences are incrementally inspected when changing directories, so it will "leave" the necessary path elements before "entering" the new ones.

For example:

/foo/bar/baz$ cd /foo/biff

This would "leave" baz, then bar, and then enter biff. /foo is ignored because it is common to both paths.

And now for the motivating reason for all of these libraries...


When smartcd is combined with stash and unstash, you can achieve something pretty amazing: per-directory environment variables.  These can be useful for many things, including automagically modifying PATH, PERL5LIB, ORACLE_HOME, or any number of other settings you might want to tweak when you cd into a development directory or some other special environment.  If set up properly, they will be restored to their original values when leaving.

Let's inspect the scripts:

$ cat foo/.bash_enter
echo entering `pwd`
stash FOO
export FOO=baz

$ cat foo/.bash_leave
unstash FOO
echo leaving `pwd`

$ cat foo/bar/.bash_enter
echo entering `pwd`
stash FOO
export FOO=biff

$ cat foo/bar/.bash_leave
unstash FOO
echo leaving `pwd`

Notice that you can stash the same variable multiple times, at different levels.  Now, let's set the variable and try it out.

$ export FOO=bar

$ cd foo
entering /home/count/foo

$ echo $FOO

$ cd bar
entering /home/count/foo/bar

$ echo $FOO

$ cd
leaving /home/count/foo/bar
leaving /home/count/foo

$ echo $FOO

Enhanced by Zemanta

git only

| 2 Comments | No TrackBacks
By now, everyone knows that Git is the best source control system since sliced RCS.  I don't have to tell you about that.

Sometimes, you want to see what commits you have on a branch, but you want to see *only* the commits on that branch, and aren't on any other.  If you happen to know which branch it came from, it's simple to do something like this:

git log starting_branch..new_branch

But if you don't know or care where it came from, this is more difficult.  In order to do this, you might craft a complicated command line that looks something like this:

git log $(git rev-parse --not --branches | grep -v $(git rev-parse <branch>)) <branch>

but this is impossible to remember, and annoying to type.  Fortunately, Git makes it trivial to add commands in several ways:

  1. Create a program and put it in your $PATH, and name it git-something, which then allows you to run "git something"
  2. Make an alias, which can simply add arguments to other git commands, or which can shell out to a system command

For this problem, I chose the second option.  However, since the convoluted command I wrote above requires you to pass the <branch> argument twice, an ordinary alias is not sufficient.  I decided to use a shell function to help.

First, we'll define the function.  You can put this in your .bashrc or .bash_profile, or somewhere similar:

git_only() {
    opts=$(git rev-parse --no-revs "$@" 2>/dev/null)
    rev=$(git rev-parse --revs-only "$@" 2>/dev/null)
    if [[ -z $rev ]]; then
        branch=$(git name-rev --name-only HEAD)
    git log $(git rev-parse --not --remotes --branches | grep -v $(git rev-parse $branch)) $branch $opts

Note that it uses git's rev-parse command to separate options from revisions, so that you'll be able to pass most arguments to this that you'd normally pass to "git log", including -- pathspecs

Then you need to export the function so that sub-shells can also see it

export -f git_only

Finally, you simply add it to git's config as an alias:

git config --global alias.only '!git_only'

And that's it!  Now you're ready to try it out:

$ git only origin/foobar

As written, this does have a couple of shortcomings:

  1. Any "revision arguments" will be eaten by rev-parse, so things like --no-merges wont work
  2. Since refs are parsed to SHA1s before grepping out the one that you want to inspect, if it's exactly identical to another branch, it will still be shown even though it's not actually unique
If I figure out workaround to those issues, I'll update the post with a new version of the function.

About this Archive

This page is an archive of entries from June 2010 listed from newest to oldest.

May 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.