zsh does not require cd to change directories.

Using the directory as a command implies “cd”. For example, instead of doing:

me@server:/home/me $ cd /tmp
me@server:/tmp $

You can just do:

me@server:/home/me $ /tmp
me@server:/tmp $

That’s three whole keystrokes (nearly half the command shown above), all day long.

The whole process is much easier with compilation-perl.el. This handy bit of code sets up patterns for compilation-mode so that test failures (among other things) are recognized. Just add compilation-perl.el to your emacs lisp directory and follow the directions at the top of the file for installation instructions.

So my test process is now:

1. Hit F4 (which I have mapped to compile).
2. If necessary, change the command to either make test or to run a specific test I’m working on (e.g. perl t/MyModule.t).
3. If there’s a failure, press C-F4 (which I have mapped to next-error) and it brings me right to the failure.
4. Repeat from step 1 (but the second time around I don’t need to do step 2 since the command is already set properly).

The process for building debian packages is actually very well documented, though many of the tutorials you will find are aimed at people who are packaging third-party software instead of their own.

Also, I’m running on Debian’s Lenny, and I need to produce packages that install cleanly on Ubuntu’s Jaunty Jackalope. It sounds worse than it is.

Take this with a grain of salt — it works for me, but I’m certainly not an expert in this area.

Steps:

1. Debianize each package. (Here’s an excellent quick & dirty guide to getting a package created.)
2. Build the packages: (cd MYPROJECT; fakeroot ./debian/rules binary). Don’t distribute these packages, they are probably wrong! But this is the quickest way to get everything mostly-working.
3. Sanity check the packages: dpkg-deb -c MYPROJECT.deb; dpkg-deb -I MYPROJECT.deb; dpkg -i MYPROJECT.deb

4. Check in your MYPROJECT/debian/ directory to source control (e.g. git, svn, etc).
5. This is the tricky step, and one that I didn’t see explicitly documented.You need a version of debootstrap that knows about ubuntu distributions. (Ubuntu debootstrap knows about Debian, but not the other way around.)
   1. Download the jaunty (or whatever ubuntu version) debootstrap source package. Grab the .dsc and .tar.gz from that page.
   2. Run dpkg-source -x debootstrap_1.0.20~jaunty1.dsc — this extracts the source.
   3. (cd debootstrap-1.0.20~jaunty1; debuild -uc -us) — this will build a .deb you can install on your lenny machine. Install package “devscripts” if you don’t have debuild.
   4. sudo dpkg -i debootstrap_1.0.20~jaunty1_all.deb
6. Install pbuilder. This will help you build the packages in a clean chroot — i.e. without all the pollution you have on your machine that could be making the packages work even though they will break on your users’ machines.
7. Put the code found here in your ~/.pbuilderrc.
8. Apply this sudoers change (optional but convenient).
9. sudo DIST=jaunty pbuilder create … then wait. (If you have lame internet service (Hughes) and a daily bandwidth cap, you may want to schedule this for the free-for-all period: echo sudo DIST=jaunty pbuilder create | at 2:30am tomorrow)

If you see anything I’m missing or would like to add, please drop a comment below. Thanks!

If you want to experiment with history expansion a bit, you can echo the result instead of executing it:

hostname:~/dir% ls /some/long/path/to/file_0.1-2_i386.changes
hostname:~/dir% echo !?ls?:s/-2/-3/
echo ls /some/long/path/to/file_0.1-3_i386.changes

In this case, what I wanted to do is repeat a long command that referenced a file with a version number in it — but I wanted to use a different version number (-3 instead of the previously given version -2).

History expansion uses “!” (“bang”, or exclamation point). If you want to select the previous command to expand based on a string match, “!?str” will find the previous command that contains “str”. If you want to substitute some part of that previous command, put another question mark on the end, add a colon, and use the the “s” modifier. In the example above, “!?ls?” means expand the previous command containing “ls”. The “:s/-2/-3/” means modify that expanded command to replace the occurrence of “-2″ with “-3″.

(Of course, to actually get all of that figured out and working, I had to iterate the sequence of commands above about a dozen times.)

Leave a comment with your favorite zsh history trick. Thanks!

Set your prompt by setting $PROMPT. If you do PROMPT='foo ', the shell will give you a foo prompt for every command. Not terribly useful but you get the point.

There are a bunch of codes you can use in the value of PROMPT to get useful output. For example, %m gives the name of the machine you’re running on, and %~ gives the name of the current working directory. For a list of all the codes, check the “zshmisc” man page under the section “SIMPLE PROMPT ESCAPES”. Note that there are codes for boldface, underline, and colors here too.

The drawback to having all kinds of information in your prompt is that you limit the length of commands that you can enter without scrolling. Scrolling stinks because the command is harder to read. Enter the “right prompt”. Set RPS1 to contain the lengthy part of your prompt, and it will be displayed on the right margin of your terminal. Then when commands get long and encroach on the right prompt, it will conveniently disappear. Read Quentin’s comment on this zsh post.

Here’s a gotcha with RPS1 and fancy prompt formatting: gnome-terminal does not behave well when these are set. I’m trying out alternatives to see which will be better.

Lastly, a trick I picked up from Justin. Zsh provides hooks that you can use to do things before and after a command runs. Just define the functions preexec and precmd. This example sets the title of the xterm while a command is running:

function title() {
    # escape '%' chars in $1, make nonprintables visible
    local a=${(V)1//\%/\%\%}

    # Truncate command, and join lines.
    a=$(print -Pn "%40>...>$a" | tr -d "\n")

    case $TERM in
        screen*)
            print -Pn "\e]2;$a @ $2\a" # plain xterm title
            print -Pn "\ek$a\e\\"      # screen title (in ^A")
            print -Pn "\e_$2   \e\\"   # screen location
            ;;
        xterm*)
            print -Pn "\e]2;$a @ $2\a" # plain xterm title
            ;;
    esac
}

# precmd is called just before the prompt is printed
function precmd() {
    title "zsh" "%m:%55<...<%~"
}

# preexec is called just before any command line is executed
function preexec() {
    title "$1" "%m:%35<...<%~"
}

Update: Set variable a to local in function title above as suggested in the comment below.

# This controls what the line editor considers a word. By default it
# includes '/', which makes it so that when I M-del (attempting to erase
# a directory in a path), I erase the whole path. Annoying.
# WORDCHARS='*?_-.[]~=/&;!#$%^(){}<>' # (default)
WORDCHARS='*?_-.[]~=&;!#$%^(){}<>'


After living with this for a while, I realize that I should probably remove the underscore too, since that’s what I was used to in bash.

1. sudo aptitude install zsh
2. chsh /bin/zsh

That’s pretty simple.

Of course, you’re not running zsh yet… either logout and log back in or just run zsh at the prompt. You’ll get a series of prompts to configure a .zshrc. It only takes a few minutes, so run through the options and save the file.

Next up: setting a custom prompt.

1. Source control. This almost belongs in the “if you don’t have it, you aren’t making software” category. There are so many free and simple to use tools that it is ridiculous to not use source control. Pick one of: subversion, git, or any of the dozens of other free tools and use it. I guess I’d say “if you don’t have it, you are making a mess”.
2. Bug/issue tracker. Trac is a decent tool for keeping tabs on development tasks and bugs. Bugzilla is ok too. If you have a budget, there is an apparently infinite set of commercial systems available of varying quality. Almost anything is better than a list of scribbles on your whiteboard.
3. Backup server. You can do software without it, but the odds are against you lasting long.
4. Build system. Automated nightly/continuous builds are awesome. Whether you DIY, install something free like hudson, or purchase a commercial system, this is a key piece of making sure that the software maintains at least a minimum level of quality (i.e. it is always buildable). After having worked on a couple of teams that didn’t have such a system, and the build was always broken, I would never work without it again.
5. IM / Jabber. Especially with a conference server where the rooms are archived and available via the web. Searchable is nice, but making them available where they can be grepped isn’t bad either. I didn’t become convinced of the value here until last summer.It sounds like an extra distraction and sometimes it can be, but you can turn it off when you’re heads-down coding. And it has the potential to reduce the number of interruptions from people walking into your office with questions that could have been answered in an IM. It’s lighter weight than email and rooms are broadcast by nature so you don’t have to spam a huge list of people to find the answer you’re looking for.
6. Email lists. Must have web-browsable archives; the list without this has much less value. Search would be a nice bonus, though I haven’t seen it done well. This lets teams communicate a bit more formally than IM and provides a record of certain discussions and decisions.
7. FTP server. Bonus points for a TFTP server. Maybe it’s because of the nature of embedded software, but every team I’ve been on has always had to fling around large files and images. Email is horribly inefficient for this. Also, most of the products I’ve worked on needed an FTP (or TFTP) server to boot from. You’re likely to install something on your development machine, which is fine, but it’s convenient to have a central team/company internal server so you can just tell someone that a file is in your public directory on “the ftp server”. Microsoft shops and folks that don’t need to boot via FTP can probably get away with samba shares.
8. Doc server. Wiki is probably the best way to go if your team doesn’t have to produce overly-formal documentation. Wikis and formal document control systems that I’ve used have had horrible search, which sucks but I haven’t found a great solution. In the past I’ve done this with a combination of a formal doc tool plus a blog for the informal “howto” kind of notes that are always needed.
9. Code review. I can’t say I’ve worked anywhere that had a dedicated code review tool. However, when all of the development machines are on NFS so that everyone has a view of your workspace, IM fits the bill reasonably well: post a review request to the chat room with the path to your changes and get an ad hoc on the spot code review. With some discipline and a supportive culture this works very smoothly. (This arrangement could probably be done with an internal pastebin, which I haven’t listed here as must-have since I haven’t really seen it used.)

What would you add to this list? Any other tools or systems that, if missing, would make you think twice about taking a job?

Let’s say you have a half-dozen machines at work you want to log into. Instead of setting up a remote forwarding connection from each of those machines, you can have the connection from your main machine perform multiple forwardings instead of just one. This even works if some of the machines don’t support ssh.

It shouldn’t surprise you at this point that you can do this with your config file. On your work machine, you might have something like:

Host tunnel
  HostName cloud.example.com
  User mycloudusername
  IdentityFile ~/.ssh/id_dsa
  Port 22
  RSAAuthentication yes
  PubkeyAuthentication yes
  ExitOnForwardFailure yes
  # tunnel ssh to myworkmachine
  RemoteForward 4022 localhost:22
  # tunnel remote desktop to mywindowsbox via myworkmachine
  RemoteForward 5389 192.168.4.10:3389
  # tunnel http to mywindowsbox via myworkmachine
  RemoteForward 5080 192.168.4.10:80
  # tunnel remote desktop to otherwindowsbox via myworkmachine
  RemoteForward 6389 192.168.4.11:3389
  # tunnel ssh to workserver via myworkmachine
  RemoteForward 7022 192.168.4.2:22

You can add a bunch of forwardings as shown above. Each entry will open the given port on cloud and forward it to the specified port on the specified machine. Now when you run “ssh tunnel” on your work machine, it will connect to cloud and set up the five port forwardings specified in your config file.

Then when logged in to cloud.example.com, you can do, for example, “ssh -p 7022 myserverlogin@localhost” to log into the machine called workserver.

If you mirror the remote forwardings in your home config file as local forwardings, then when you “ssh work” from home you can remote desktop to a windows machine from your home pc by doing “rdesktop -u myworkwinuser localhost:5389″ and it will use the tunnel. (The connection will go from your home pc to cloud, to myworkmachine, to mywindowsbox.) The windows machine does not need to know anything about ssh.

As I mentioned in a previous post on ssh configuration, your config file can specify a variety settings for each server.

In fact, the Hosts you use don’t even have to exist! (The HostName is the important part.) Consider the following snippet in your ~/.ssh/config.

#
Host work
  HostName localhost
  User myworklogin
  IdentityFile ~/.ssh/id_dsa
  Port 4022
  RSAAuthentication yes
  PubkeyAuthentication yes
  LocalForward 4022 localhost:4022

I’m going to assume remote forwarding is set up and the connection is open from work to cloud as described in this post on remote forwarding; and you’ve got local forwarding set up from home to cloud as described in this post on local port forwarding.

Now you can do “ssh work” from your home pc, and it will automatically log you into your work pc with the right credentials using the tunnel on cloud.example.com. And the scp example above simplifies to “scp work:/tmp/foo.txt ~/foo.txt” — you don’t have to remember the forwarded port numbers.

Typing “ssh work” is nine keystrokes (eight letters plus enter). If you can type 40 wpm, that’s 200 keystrokes per minute, or 3.33 keystrokes per second, which means you can open the tunnel in four seconds!

If you add “alias ssw=’ssh work’” to your ~/.bashrc, you’re down to four keystrokes.