A really simple personal bug tracker, using just the Unix shell
When working on my personal projects, I find that I often get overwhelmed with ideas and possibilities, causing me to lose track of what needs to be done first, what is important, etc. Some kind of bug tracker would be helpful, except most of them are overkill for my purposes, IMHO. Also, they tend to be platform-dependent (whereas I tend to develop on multiple operating systems) or web-based (and I don't always have internet access). So, I started looking for something Really Simple.
As it turns out, the following is sufficient for my needs:
- store bugs/ideas as simple text files;
- use a Unix shell (or similar) to manipulate these files.
Again, this is for *personal* bug tracking. I don't work with other people on these projects. Also, I don't need fancy reports, or a polished user interface. It is meant to be extremely simple.
Anyway, so I thought I'd share this. (Feeble disclaimer: The idea probably isn't new. Hell, maybe it's decades old; if so, I still find it useful.)
This is how it works:
Filenames look like xxxxyz, where xxxx is the number of the item, y is a letter indicating the status (like "o" for open and "c" for closed), and z is a digit indicating the priority. For example, a filename might look like 0007o2, which tells us that this is item #7, it's currently open, and has priority 2.
You add a new item simply by looking at the last number used, and creating a new file with that number plus one, and the desired priority, in your favorite editor. In other words, if I have 27 bugs in my directory, then I create the next one by doing vim 0028o3, or something like that. (I figure you could write a script for this, or maybe it's a one-liner given the right tools... but it seems like overkill when all you need to figure out the next number is ls.)
These files are just text files. They don't have a special format, *except* that the first line should be the title, or a summary of the item. Anything after that has no special meaning. (The reason for this will become clear soon.)
Now, we are ready to unleash the awesome power of the Unix shell onto these files! :-)
Show all open/closed bugs:
$ ls *o* $ ls *c*
Show a specific bug:
$ cat 0024<Tab><Enter> # or open it in an editor, of course
Show the number of open bugs:
$ ls -l *o* | wc -l
Show the summaries of all open bugs with priority 1:
$ head -1 *o1
(This is why it's useful to have the title on the first line... head -1 will display just the title. If there are multiple files matching the "*o1" pattern, head will display the names of the files as well.)
Search bugs for the text "refactoring":
$ ack -ui refactoring * $ grep -i refactoring *
(I use the ack tool, but grep works as well.)
List complete entries for all open bugs with priority 1:
$ head -h 1000 *o1
(Assuming no file has more than a thousand lines. If it does, maybe it's time to split it up...)
Changing status/priority is just a rename:
$ mv 0024o1 0024o2 # or, when files are in svn: $ svn mv 0024o1 0024o2 --force
Notes:
1. Naturally, you can change the filenames to suit your needs and preferences. I use priorities 1-5, where 1 is the most urgent, but one might well use 1-3 or 1-9, etc. Similarly, there could be more status indicators than just "o" and "c". There could be additional indicators for the type of item (bug, idea, feature), and so on.
2. When I say "Unix shell", I really mean an environment that is similar to sh. Linux and OS X have actual Unix shells; Windows has Cygwin, but in a pinch, 4NT could be used as well (or these days it's Take Command).
Jesper Noehr said,
May 15, 2008 @ 1:19 am
I haven't tried it, but I've heard good things about Ditz: http://ditz.rubyforge.org/
Brian H said,
May 15, 2008 @ 1:58 am
neato!
nande! said,
November 26, 2008 @ 9:23 am
very good idea, :D