Monthly Archives: February 2012

TarColor: color the output of tar tvf similarly to the way GNU ls would

Posted on by
Reply

One day I was looking through a tar file and looking for an executable. When I use ls, I can do this at a glance by just looking for green filenames, as I always have my ls configured to show executable files in green. It occurred to me that it would be nice to see the same kind of coloring when looking at the contents of tar files with tar tvf. Thus, TarColor was born. It was a quick Perl script to scratch my own itch. I thought others might find it useful, so I put it on GitHub and CPAN.

Usage

You can use tarcolor manually like this:

$ tar tvf some_tarball.tgz | tarcolor
... colored output ...

There is also a bundled shell script (for bash and zsh) that makes tar automatically pipe its output through tarcolor:

$ source /usr/local/etc/tarcolor/tarcolorauto.sh
$ tarcolorauto on
$ tar tvf some_tarball.tgz
... colored output ...
$ tarcolorauto off
$ tar tvf some_tarball.tgz
... normal uncolored output ...

Customization

Colors can be customized using the LS_COLORS or TAR_COLORS environment variables:

$ export LS_COLORS='di=01;34:ln=01;36:ex=01;32:so=01;40:pi=01;40:bd=40;33
:cd=40;33:su=0;41:sg=0;46'

The format for LS_COLORS and TAR_COLORS is the same format used by LS_COLORS (used by GNU ls). So if you use GNU ls and have your LS_COLORS set, then tarcolor will use similar colors as ls. If you want to tweak your colors and don’t want to edit LS_COLORS manually, you might try this online LS_COLORS generator.

Links

Installing GNOME in FreeBSD 9

Posted on by
Reply

I pretty much followed these instructions, but one extra step was required.

The problem that I was having was that the system kept running out of file descriptors and becoming unusable. After a little digging around with fstat and such, it was apparent that gam_server from Gamin was the culprit, using some 3700 file descriptors. From a bit of web browsing, I saw that this is somewhat common on BSD, because BSDs don’t have inotify like Linux, so Gamin uses kqueue but this requires opening files and using file descriptors. This is described in the Gamin Wikipedia page.

My solution was to increase the number of file descriptors by adding to /boot/loader.conf:

kern.maxfiles="25000"

This was enough file descriptors to placate gam_server:

[marca@freebsd9-0 ~/src]$ fstat | grep gam_server | wc -l
    6435

Why you don’t get mock objects

Posted on by
Reply

Why you don’t get mock objects

Fascinating talk by Gregory Moeck from RubyCon 2011

While this deals quite a bit with TDD and mock objects, it’s also largely about a particular style of OO design, one that reminds me a lot of some of Allen Holub’s writings. It’s not very specific to Ruby (it has some examples in RSpec – that’s about the extent of the Rubyness).

Fixing VMware guestOS setting after the fact

Posted on by
Reply

I set up an OpenIndiana vm in VMware Fusion (see earlier post) but while setting it up, I accidentally selected “Other” for the guest OS type instead of “Solaris”. As a result, later on when I wanted to install VMware Tools, it wasn’t available in the menu because the system didn’t know which CD image to mount.

The fix was to edit the guestOS setting in the .vmx file.

But first I needed to figure out what the valid settings are for guestOS.

I took a clue from this page and did this:

$ strings '/Applications/VMware Fusion.app/Contents/Library/vmware-vmx' | egrep '^solaris[0-9]'
solaris6
solaris8
solaris9
solaris10-64
solaris11
solaris11-64
solaris10
solaris7

From this, I knew that I needed to put:

guestOS = "solaris11-64"

in /Users/marca/Documents/Virtual\ Machines/OpenIndiana\ Build\ 151a\ Desktop.vmwarevm/OpenIndiana\ Build\ 151a\ Desktop.vmx

Setting up OpenIndiana b151A

Posted on by
2

I’m in the process of installing OpenIndiana b151A in a VMware Fusion virtual machine.

Main reason is that I’ve become interested in DTrace and DTrace comes from the world of Solaris. OS X has DTrace too, but I’m noticing that it differs quite a bit from DTrace on Solaris, especially when it comes to developing with it — i.e.: instrumenting software with USDT probes.

OmniFocus sqlite completedDate

Posted on by
3

A while back, I posted about how OmniFocus maintains a sqlite database. This could be really interesting for writing software to do new stuff on that data.

Jared just dug into this and noticed that the completedDate field was an integer, but it did not appear to be a unix epoch time.

I just did a little experimentation and it seems that OmniFocus is setting dateCompleted to the number of seconds since Jan. 1, 2001 00:00:00 GMT.

I figured this out by setting my time zone in System Preferences to GMT and then I went into OmniFocus and created a task and set the completion date to “1/1/01 00:00:00″. Then in sqlite:

sqlite> select name, dateCompleted, datetime(dateCompleted + 978307200, 'unixepoch', 'localtime') from task where dateCompleted is not null;
...
Take clock out of Honda                 351241538.054  2012-02-18 07:05:38
Ate sushi                               351241498.856  2012-02-18 07:04:58
Order replacement light bulb from Amaz  351241558.269  2012-02-18 07:05:58
Test -- item completed on 2001-01-01 0  0              2001-01-01 00:00:00

and after setting my timezone back to GMT-8:

sqlite> select name, dateCompleted, datetime(dateCompleted + 978307200, 'unixepoch', 'localtime') from task where dateCompleted is not null;
...
Take clock out of Honda                 351241538.054  2012-02-17 23:05:38
Ate sushi                               351241498.856  2012-02-17 23:04:58
Order replacement light bulb from Amaz  351241558.269  2012-02-17 23:05:58
Test -- item completed on 2001-01-01 0  0              2000-12-31 16:00:00