Here is a screenshot illustrating the clean and then dirty state of the development branch.

1. Who am I?
2. Where am I?
3. Which branch of a Git repository am I on?

I wanted color. I wanted a multiline prompt. I wanted it all!

Actually it was pretty easy. Here it is, explanation to follow:

source ~/.git-completion.sh

export PS1='\[\e[0;32m\]\w\[\e[1;33m\]$(__git_ps1 "(%s)")\[\e[0m\]\n\u $ '

The first line loads .git-completion.sh a script distributed with Git that provides autocompletion for Git. Cool! But it also provides the function at work in:

$(__git_ps1 " (%s)")

This will display the branch currently checked out when you are in a Git repository.

The characters:

\[ \]

wrap nonprinting characters, in this case, the color codes:

\e[0;32m
\e[1;33m
\e[1;33m

Finally:

\w
\n
\u

gives you the name of the current directory, a new line, and your user name, respectively.

Well a picture is worth a thousand words:

I recently learned a few things about bash history that’s made me more productive on the command line, so I thought I would share.

Searching Bash History

Almost anyone who has spent any time at all on the command line will know that you can move backwards and forwards through the history of previous commands with the up and down arrow. Suppose, however, you want to rerun a previous command issued several command lines before. You could bang away at the up arrow. But this is tedious and error prone—you can easily overshoot the target command line.

Fortunately there’s a better way. Bash allows you to search backwards through your history with ⌃R. After typing ⌃R begin typing the string that you are searching for and the bash shell will return the most recent matching string. To search further back in your history for other matches hit ⌃R as many times as necessary. Nice.

Old School

The bash history predates the emergence of arrows on keyboards. So there are ways to move through bash history with these. Thus:

!!

takes you to the previous command line. What’s the point, you might wonder? Why bother to use three keystrokes when one (up arrow) will do? Well, you can use !! with other elements of a command line:

$ tree
-bash: tree: command not found
$ ~/bin/!!
~/bin/tree

Nothing similar can be accomplished with the up arrow.

The bash history is a numbered list of command lines issued to the shell. You can select a particular command line using !n where n is the number of the command.

One of the most useful commands for traversing bash history is !$ which gives the last argument of the previous command:

$ mkdir -p myproject/src
$ cd !$
$ PWD
/Users/markelikalderon/myproject/src

Another useful command is !* which gives all of the previous commands. This can be useful for correcting (sadly inevitable) typing errors:

$ sbn commit -m "Initial commit"
bash: sbn: command not found
$ svn !*
svn commit -m "Initial commit"

Another way of dealing with this typo is to use a quick substitution with the caret ^.

$ sbn commit -m "Initial commit"
-bash: sbn: command not found
$ ^sbn^svn
svn commit -m "Initial commit"

There’s more, much more, that can help you traverse the command line efficiently. As ever, RTFM, baby.

Update: There is more on bash history on the TextMate Blog.

Earlier I noted how current writing technology tends to be the dominant metaphor of the mind. Related to this, is the tendency for writing technology to make a technological platform. Texting was the killer app for the cell phone, and the wordprocessor was the killer app for the PC. But before that, there was UNIX, and the killer app for UNIX was troff.

Part of the Documenter’s Workbench (DWB), troff was first used to process documents in the Bell Labs patent department. Dennis Ritchie describes the event in “The Evolution of the Unix Time-sharing System”:

At the time of the placement of the order for the PDP-11, it had seemed natural, or perhaps expedient, to promise a system dedicated to word processing. During the protracted arrival of the hardware, the increasing usefulness of PDP-7 Unix made it appropriate to justify creating PDP-11 Unix as a development tool, to be used in writing the more special-purpose system. By the spring of 1971, it was generally agreed that no one had the slightest interest in scrapping Unix. Therefore, we transliterated the roff text formatter into PDP-11 assembler language, starting from the PDP-7 version that had been transliterated from McIlroy’s BCPL version on Multics, which had in turn been inspired by J. Saltzer’s runoff program on CTSS. In early summer, editor and formatter in hand, we felt prepared to fulfill our charter by offering to supply a text-processing service to the Patent department for preparing patent applications. At the time, they were evaluating a commercial system for this purpose; the main advantages we offered (besides the dubious one of taking part in an in-house experiment) were two in number: first, we supported Teletype’s model 37 terminals, which, with an extended type-box, could print most of the math symbols they required; second, we quickly endowed roff with the ability to produce line-numbered pages, which the Patent Office required and which the other system could not handle.

During the last half of 1971, we supported three typists from the Patent department, who spent the day busily typing, editing, and formatting patent applications, and meanwhile tried to carry on our own work. Unix has a reputation for supplying interesting services on modest hardware, and this period may mark a high point in the benefit/equipment ratio; on a machine with no memory protection and a single .5 MB disk, every test of a new program required care and boldness, because it could easily crash the system, and every few hours’ work by the typists meant pushing out more information onto DECtape, because of the very small disk.

The experiment was trying but successful. Not only did the Patent department adopt Unix, and thus become the first of many groups at the Laboratories to ratify our work, but we achieved sufficient credibility to convince our own management to acquire one of the first PDP 11/45 systems made.

Troff interprets a presentational markup and has a number of preprocessors for specialized tasks such as the construction of tables. As a modularized system connected by text streams, troff anticpates more modern systems for document production such as LaTeX and XML (though these represent an increasing move away from presentational to structural markup). For more information about troff see chapter 8 and chapter 18 of the Art of Unix Programming

The version control bundle requires GNU awk. If gawk is not installed on your *nix system, this script will do it for you:

#!/bin/sh
#
# installgawk.sh
#
# A bash script to install the latest version of GNU awk. Be sure to set the variables to the desired values. 
#
# http://www.gnu.org/software/gawk/
#
# Mark Eli Kalderon 2008-03-22

# Gawk. Change to the desired version if necessary
VER="3.1.6"
GAWK="gawk-${VER}"

# Build directories. Change to the desired directories if necessary.
GBLDDIR=/var/tmp/${GAWK}-build

# Create gawk build directory, but save source files if they exist.
test -d ${GBLDDIR} || mkdir ${GBLDDIR}
test -d ${GBLDDIR}/${GAWK} && /bin/rm -rf ${GBLDDIR}/${GAWK}
cd $GBLDDIR

# Download and unpack gawk source.
curl http://ftp.gnu.org/gnu/gawk/${GAWK}.tar.gz -O
tar -xvzf ${GAWK}.tar.gz
cd ${GAWK}

# Configure and build gawk.
./configure
make
make check

# Install gawk (in /usr/local/bin/). Will prompt for password.
sudo make install

As of version 0.3, the vc bundle supports bazaar, git, and subversion and runs on Windows and unices. Within the vc directory there are subdirectories for each of these cases:

• bzr-unix/
• bzr-windows/
• git-unix/
• git-windows/
• svn-unix/
• svn-windows/

Each of these subdirectories contains a pair of scripts. As I am on OS X and wanted to see how well this would work with git, I used the scripts in git-unix/:

• vc
• vc-git.awk

Copy these to the root directory of your repository. vc is a shell script that extracts version control information and writes it to a new file, vc.tex. vc does this by calling vc-git.awk to process the output of git status and git log. To use these scripts, put the following in the preamble of your LaTeX document:

\immediate\write18{sh ./vc}
\input{vc}

\write18 allows you to call shell scripts when running LaTeX. Most TeX installations has \write18 disabled by default for security reasons. That’s a good thing. Rather than enabling this globally, you can enable this on an as needed basis, by running pdflatex or xelatex with the -shell-escape argument.

vc.tex defines the following macros which can now be used in your LaTeX document:

• \VCRevision current (maximum) working copy revision number
• \VCRevisionMod as \VCRevision, but with an additional note if the working copy contains modified files
• \VCAuthor author of the last check-in operation
• \VCDateRAW date of last check-in in native format of the VCS software
• \VCDateISO date of last check-in in ISO format YYYY-MM-DD
• \VCDateTEX date of last check-in in TeX format YYYY/MM/DD
• \VCTime time of last check-in
• \VCModifiedText contains the note shown in macro \VCRevisionMod if there were modified files. This macro can be redefined by the user.
• \VCModified 0 if there are no modified files in the working copy directory; 1 or 2 if there are modified files. In general you don’t need this macro.

These macros can be called wherever appropriate. I wanted my version control information discretely tucked away in a footer:

\usepackage{fancyhdr}
\lfoot{\tiny{Revision: \VCRevision ; Author: \VCAuthor ; Date: \VCDateISO}}
\cfoot{}
\rfoot{}

The result:

If you want the version control information in draft mode only, Stephan Hennig, vc bundle’s maintainer, suggests using the ifdraft package.

$ perl texWordCount.pl /Users/markkalderon/Documents/TheHub/Research/Metamerism/Drafts/metamerism.tex

and you realize you have forgotten an option, in this case -T:

$ perl -T texWordCount.pl /Users/markkalderon/Documents/TheHub/Research/Metamerism/Drafts/metamerism.tex

it can be tedious to move to the beginning of the line, character by character, to insert it. Fortunately, bash, the default shell on OS X, has an emacs mode allowing you to use a subset of emacs commands on the command line. Emacs uses two modifier keys—control and meta. On OS X control is ⌃ and meta is ⎋.

PS1="\n\
\$PWD\n\
$BOLD\h-\u$DIM $ "; export PS1
PS2="more=> "; export PS2

Which produces the following shell prompt:

How apt a solution this is will depend, of course, on how precious vertical space in the terminal is to you. (Dr. Drang mentioned something about his left eye twitching uncontrollably.) So your mileage may vary.

|-- root/
    |-- foo/ (the present directory)
    |-- bar/

then ../bar/ would be the relative path for bar from foo (../ takes you up to root and bar/ takes you down to bar).

UNIX 101, I know, but what I did not know until just recently is that LaTeX accepts *nix relative paths. Which is awesome. That means complex LaTeX projects can live in a structured directory with, say, subdirectories for graphics. Suppose you are writing an article with graphics, your directory could be laid out as follows:

|-- mylatexproject/
    |-- tex/
        |-- article.tex
    |-- graphics/
        |-- mygraphic.jpg

To insert mygraphic.jpg in article.tex you could then use:

\insertgraphic{../graphics/mygraphic.jpg}

I plan to start work on my next book this summer. I am so glad that I sussed this out before then.

Another hybrid application from Apple is Activity Monitor:

Of course a lot of the information displayed by Activity Monitor can be accessed by top in the terminal, but there’s more besides. In a How To article in About This Particular MacIntosh Sylester Roque begins the first part of a review of the Activity Monitor. Check it out to get a sense of the potential of this underappreciated utility.

While on the topic of ATPM, Ted Goranson in his column about outliners (text editors that allow multiple views of a document based on its logical structure), will be writing about writing environments next month. If you are not yet familiar with this fascinating column, the archives are a rewarding read.

I was also wrong.

While I would never go back to working entirely in a terminal, I now understand that the ascendancy of the GUI represents the triumph of the Image over the Word. The visual editing of word processing provided merely the illusion of control and was, in fact, inimical to writing.

In exploring the UNIX underpinnings of OS X, I was pleased to discover that a lot of tools that programmers use are, in fact, readily adaptable to the task of writing.

In dumping word processing for something better, I received a lot of help from people sharing their knowledge online. As thanks and a small token of respect, I will be posting some of what I have learned here.