Traditionally, Unix has operated by piping between commands ("find | grep | sort | uniq"). I wonder if we are experiencing a shift to command composition being a more common model?

I started thinking about this when I considered the following command line:

chronic mr run git annex get

Unpacking, that uses chronic, which arranges for quiet running of mr (unless it fails, then it shows the full output), which in turn runs git in every repository it knows about, and git is asked to run the git-annex subcommand, which in turn has a "get" subcommand of its own.

So, in other words, this is a cron job that syncs large files in a set of git repos, quietly. You might want to make it run niced also, which adds 3 more commands:

chronic nice ionice -c3 trickle -d100 mr run git annex get

This is the most extreme example I know of (unless you tack in a "sudo"), but there does seem to have been a gradual shift to using more composition, and more subcommands. In git in particular, two-levels of subcommands is not unknown, for example "git remote add". Subcommands, especially as implemented in git (or earlier, in arch), are kind of a special case of command composition that adds a namespace. I'm sure that a count of commands with subcommands would show it exploded in the past 10-12 years. I'll bet a count of composable commands would also show a significant increase.

Anyone have other examples of long compositions of commands?

Here at the Hollow in what can euphemistically be called a "cabin", there is no cell service, and I have not signed up for long distance, as all the phone is normally used for is to call a local dialup internet number.

It would be nice to be able to occasionally make outgoing long distance calls in this situation though. With some difficulty, Google voice can be used in this situation.

The difficulty is because my google voice number is itself a long distance call from here, so I can't just call it up and use it as intended. And google voice's web interface was not designed with dialup in mind; it assumes you have a phone line that's not carrying your internet connection.

verifying the phone

This is the tricky part. Google voice wants to call you back on your phone and have you verify a number. To start this process, you need to use the internet. It's impossible to hang up from the net before they call back.

Since it's a one-off, I didn't try to automate this, and just had someone do the internet side of the verification, call me with the number, and then trigger google voice to call me back.

(Google voice's forums are full of similar stories.)

making outgoing long distance calls

Here's the fun part. You'll need a shell account somewhere else, where you can download and install pygooglevoice.

Then create a ~/.gvoice file, filling in your login info and your phone number.

[auth]
email=
password=

[gvoice]
forwardingNumber=
phoneType=1

Now to make a call, you can just run something like this on the shell account:

sleep 2m; ./gvoice --batch call XXX-XXX-XXXX

The sleep gives you time to free up the phone line. Google voice then calls you and connects you with the number you requested.

Tomorrow I won't have to deal with it getting dark at a soul-crushing 5:30 pm. Nor will I have to wake up blearily an hour early in the spring. Instead I will be enjoying my new, custom time zone. It's "JEST", for "Joey's Eastern (non)Standard Time", and in JEST, there is no spring forward or fall back stress.

The folly of daylight savings time (Ben Franlin's best prank ever) really becomes apparent when you have solar power. It's bad enough that the sun is setting at 6:30 without compounding that by an hour. By keeping my clock set so the sun sets in midwinter at 6 pm, I will maximise what little light there is, and minimise time spent using batteries in the dark.

Of course, it helps that I'm my own boss, and that most of the people I work with are probably not in a nearby timezone anyway, and that most things are done asynchronously. Since JEST is an hour ahead of local time here in the winter, I will, at worst, tend to be running early.

So I only have to change my clocks one time -- and by "change", I mean create a custom timezone in Linux. Here's how to do that.

1. Make a custom timezone file. The standard one for North America is a bewildering 3000 lines of special cases, conflicting legistlation, and historical weirdness, but I only need one:

   echo "Zone JEST -4:00 - JEST" > JEST.zone

2. Compile and install it to somewhere; I put it in ~/.zoneinfo

   zic JEST.zone -d ~/.zoneinfo

3. Set TZ to use it. Also TZDIR if it's not in the system directory.

   export TZDIR=~/.zoneinfo TZ=JEST

Update: Turns out it was easier than I thought, just setting TZ=FOO+4 will make date display a timezone "FOO" that is 4 hours behind GMT. So all I need is to set TZ=JEST+4

Result:

date: Sat Oct 30 21:43:39 JEST 2010
date -R: Sat, 30 Oct 2010 21:43:39 -0400

Previously:

• daylight savings time idiocy
• DST: no power saved
• daylight savings crime
• fall back day

Also, for Android:

Android does not seem to have an way to define your own time zone. I select Barbados from the time zone list, since it is on GMT-4 year round with no daylight savings.

I've hooked one of my laptop's terminals up to the net, so anyone with IPv6 can telnet in and see it.

I've long wanted to be able to broadcast my terminal sessions on occasions when it makes sense. Like when I'm fixing someone's bug, or closely collaborating with someone distant.

I am also interested in finding things to host on IPv6. Right now, that means only people who care will be able to access it. So it seems the trick is to find places where that is a benefit. I plan to keep an eye out for more things like this.

(A side benefit of using IPv6 is that it makes it easier to serve content from my laptop, that moves from network to network.)

So, tune in to my termcast!

termcast

I was thinking about how I often end up in a directory path where the names of one or more components repeat. It seemed there should be a name for when this happens.

/home/joey/src/ikiwiki/doc/ikiwiki/
/home/joey/src/pdmenu/src/
/home/joey/src/joeywiki/joey/
/lib/modules/2.6.26-2-686/kernel/lib/
/proc/1/task/1/

Then I realized there was a name already: Fractal. While directory structures are supposedly hierarchical, different levels in the hierarchy are self-similar, and so sometimes the same name is duplicated, with a subtly, or vastly different meaning, at different levels in the same directory path.

I had wondered if we were doing something wrong, that this happens so often. It is occasionally confusing. But aside from using a deep, nominally hierarchical directory structure, and displaying a slice through it (as if talking about electron orbitals in a rock orbiting sol), I don't think we're doing anything wrong.

Here is a oneliner that will find all such directories inside a specified start directory. You will probably find some amusing ones you've never noticed.

perl -MFile::Find -le 'find(sub { if (-d $_) { my %bits; foreach $bit (split "/", $File::Find::name) { if (++$bits{lc($bit)} > 1) { print $File::Find::name; return } } } } , shift || ".")'