* Scripting the Vim editor, Part 1: Variables, values, and expressions
* Scripting the Vim editor, Part 2: User-defined functions

The latter has a very useful example.

function AlignAssignments()
   " Patterns needed to locate assignment operators. "
   let ASSIGN_OP   = '[-+*/%|&]\?=\@<!=[=~]\@!'
   let ASSIGN_LINE = '^\(.\{-}\)\s*\(' . ASSIGN_OP . '\)'
 
   " Locate block of code to be considered (same indentation, no blanks) "
   let indent_pat = '^' . matchstr(getline('.'), '^\s*') . '\S'
   let firstline  = search('^\%(' . indent_pat . '\)\@!', 'bnW') + 1
   let lastline   = search('^\%(' . indent_pat . '\)\@!',  'nW') - 1
   if lastline < 0
       let lastline = line('$')
   endif
 
   " Find the column at which the operators should be aligned. "
   let max_align_col = 0
   let max_op_width  = 0
   for linetext in getline(firstline, lastline)
       " Does this line have an assignment in it? "
       let left_width = match(linetext, '\s*' . ASSIGN_OP)
       if left_width >= 0
           let max_align_col = max([max_align_col, left_width])
           let op_width      = strlen(matchstr(linetext, ASSIGN_OP))
           let max_op_width  = max([max_op_width, op_width + 1])
       endif
   endfor
 
   " Code needed to reformat lines so as to align operators. "
   let FORMATTER = '\=printf("%-*s%*s", max_align_col, submatch(1),
   \                                    max_op_width,  submatch(2))'
 
   " Reformat lines with operators aligned in the appropriate column. "
   for linenum in range(firstline, lastline)
       let oldline = getline(linenum)
       let newline = substitute(oldline, ASSIGN_LINE, FORMATTER, "")
       call setline(linenum, newline)
   endfor
endfunction
 
nmap <silent> ;= :call AlignAssignments()<cr>

This allows you to line up assignments so that all the the equals appear in a column. I find this much easier to read.

To use this code, paste it into a file ~/.vim/plugin/AlignAssignments.vim. It’ll get loaded automatically. From then on you use it by going to a group of assignments and hitting ;=. Blam!

There are other alignment plugins available in the vim scripts archive, but this one is relatively small & simple.

$ ls *.{disp,frag}
foo.disp
foo.frag

Except that this doesn’t work with find:

$ find . -name '*.{disp,frag}'

Why not? Because braces aren’t globs, so they’re not supported by find(1).

What can you do instead?

Firstly, you can use the -regex flag.

$ find . -regex '.*\.\(disp\|frag\)'
./foo.disp
./foo.frag

This is particularly awful because find defaults to the emacs style of regexes (which took me ages to remember the details of) and means you end up with leaning toothpick syndrome. And you’re matching the whole filename, not a subset, so you have to have the .* on the front.

The second option is to use find’s expression language. Find THIS FILE or THAT FILE.

$ find . \( -name '*.disp' -or -name '*.frag' \) -print
./foo.disp
./foo.frag

This is a bit more readable, but you have to remember that the parentheses are quoted because the shell likes to munch on them. Overall, it does seem preferable to -regex though.

Like all these things, you can take it too far.

But in a directory full of files with similar prefixes, it’s less than helpful. I hit :e acc<TAB> and vim expands to :e acc_click_here_to_continue.html. But then I need to backspace all the way back so it reads :e acc and hit TAB again. This is a pain.

But, if you stick set wildmode=longest,full into ~/.vimrc, then vim stops when it’s completed the longest unique prefix (“acc”) and gives you a chance to type. Or, if you just keep banging on the TAB key like a deranged gibbon it will start rotating through all the possible completions. But by stopping at that point, I get a chance to intervene.

It sounds like a teeny-tiny little thing. But it’s one less thing that’s getting in the way of me doing things.

That said, any time saved has already been wiped out by writing this blog entry.

  % curl -v -H Pragma: http://example.com/

• zsh

  I spend the vast majority of my time at a command line. Zsh ensures I make best use of my time. If you’ve used bash, you might think you know what completion is—press the tab key and it fills out file names for you. But zsh takes it to a whole new level. Not only does it complete file names, but also users, hostnames, option flags, environment variables, PIDs and more. On top of that, it does it in a context-sensitive manner. So if you type in “chown ” and press TAB, it starts completing usernames. Type in a space and another TAB and it starts completing file names again.

  On top of that, it allows partial completion. If I type in /u/l/e/r/ and press TAB, It gets expanded to /usr/local/etc/rc.d/. This is phenomenally useful.

  But it’s not just completion that zsh is good at. It’s also good at globbing. That’s turning wildcards into filenames. In addition to the usual forms of globbing, zsh can glob recursively. So if I want to look for “foobar” in all my files (but not directories), I can do:

    % grep foobar **/*(.)
  

  The “**/*” is the recursive glob, and the “(.)” limits it to files and not directories. You can also limit by user, by timestamp and a few other things.

  This is just covering the surface of zsh. Suffice to say that if you make heavy use of the command line, investing some time in learning zsh will make you vastly more productive.

• screen

  This was mentioned on a few of the other lists as well. GNU Screen on the face of it doesn’t do anything. You just end up with another command line when you first run it. But the beauty of it is that if you get disconnected, you can just log back in, run screen -d -r and pick up exactly where you left off. For me, this is ideal, given the flakiness of my home wireless network. But you might want to use it so you can shut down your PC at night and pick up where you left off in the morning.

  On top of that, screen lets you run multiple command lines at once inside it, log the output and cut’n’paste between them. Think of it as a safety harness for your work.

• rsync

  Rsync is one of the closer things to magic that’s around. It’s a simple file copying utility. But the clever bit is that it only copies the things that have changed. This doesn’t sound like much until you’ve edited several files in a collection which is 200Mb and needs to be on another box. When rsync tells you it’s finished and only transferred 10Kb instead of 200Mb, you’ll really come to appreciate it.

  If you’re still using tar/gzip or zip to create an archive to ship to another computer, stop wasting your time and disk space. Learn to use rsync and your life will be far more pleasant.

• OpenSSH

  Thankfully, ssh is pretty ubiquitous these days. It seems to have mostly worked in its mission to eliminate telnet. But it has a few tricks that are worth knowing about.

  First, the agent. One of the nice things about ssh is that it doesn’t have to rely on sending passwords around. Instead, you can use public key authentication. However, even typing in your passphrase can get pretty tedious after a while for every connection. Enter the ssh-agent. Just stick eval `ssh-agent` in your startup scripts and then run ssh-add once. After that, you don’t get asked for your passphrase any more. The only caveat is that now you really need to lock your screen when you walk away from it.

  Next are the tunnels. Ssh is able to create network “tunnels” in and out of otherwise secure locations. This is very handy for creating ad-hoc networks. For example, I’m allowed to ssh into my work, but not to anything else. Yet, I can use RDP to connect to my workstation by running this command:

    % ssh -L3389:myworkstation:3389 firewall.mywork.com
    % rdesktop localhost
  

  That says: listen on port 3389, and any connections that come in, forward them on to myworkstation port 3389 from the other side of the ssh connection to firewall.mywork.com.

  If you’re on windows, check out PuTTY. It’s got all the features, but wrapped up in a nice GUI interface.

• lsof / pfiles / sockstat

  Lsof (List Open Files) is one of the first diagnostic tools that I reach for when I need to understand something. The purpose is simple: it tells you what files (and network connections) a process has open. If you’re wondering where a process is logging to, this might be able to tell you. Conversely, it can also tell you which processes have a particular file open (usually a lock file).

  On Solaris, the pfiles command is similiar.

  On a related note, FreeBSD also has the very, very useful sockstat command, which lists all open sockets and what processes hold them open. The useful bit is that it does this without needing to be root (unlike Linux’s netstat -anp).

• strace / truss / ktrace

  These are the second diagnostic tool that I reach for when something’s not right. Unix operating systems have a very clear distinction between userland and kernel, and this tool shows all the points where a program crosses between the two (makes a system call). If you really want to know how a program is interacting with its environment, these tools will tell you. It’s godo for answering questions like:

  • What files is this process opening and closing?
  • What connections to the network are being made?
  • What’s been read in by this program?

• multitail

  A recent addition to my toolbox. It’s like tail -f, except that it looks at more than one file at once. It also does highlighting of search terms. Dead handy.

• curl

  Most of the stuff I do these days involves the web. Curl is a fantastic little tool for inspecting the web from the command line. It covers all the protocols you need, and can dump out any information about the transaction. Want to issue a PUT request to an SSL server, verifying the certificate and specifing basic auth? It’s got you covered.

• vim

  Everybody needs a good editor. Vim isn’t the only choice, but it’s pretty likely to be available wherever you go. And once you’ve started learning how to use it properly, you won’t go back. In particular, I can’t live without ^P and ^N for doing completion inside the file you’re editing.

• sudo

  If you’re still using su, then you need help. Sudo allows you to dole out root access on a much more granular level and you get proper logging of who did what. If you haven’t looked at the manual recently, then check out sudo -e for editing a file as another user. It ensures that you get your regular editor (vim or Emacs) instead of the incredibly unhelpful ed that root probably defaults to.

• subversion

  Everybody needs version control. If you’re editing files, stick them in subversion. You won’t regret it. Particularly when you need to see what those files looked like 6 months ago.

• mutt

  Every now and again, you need to deal with mailbox files. Mutt is a great choice for that, thanks to its mini language for filtering mail. Need delete all mail over 10 days old sent by cron@somehost? Not a problem. Even if you don’t use it on a regular basis, it’s worth getting familiar with.

• gdb

  Yes, this is a programmers tool. But it’s worth knowing a tiny amount about if you’re a sysadmin as well. What for? It lets you see why something dumped core. If you find a core file, then do file core to see what program left it behind and then gdb /path/to/program core. When you’re inside gdb, type in where and it will (most of the time) give you a stack trace, showing what it was doing at the time of the crash. This is normally a big help in trying to figure out what went wrong.

  You can also use gdb to find out what a running program is doing by specifing a PID instead of a corefile.

• perl / python / ruby

  If you perform the same series of actions more than a couple of times, you should consider investing some time in automating the process. Shell scripts are handy, but can only go so far. Learning one of these languages will give you a really powerful ability to write your own sysadmin toolbox.

• mediawiki

  Documentation. Everybody hates doing it. Why not make it as easy as possible? A wiki is the answer to that, and mediawiki is one of the better pieces of wiki software out there. It’s pretty simple to get going (although it does depend on MySQL).

  Remember: getting it documented is first priority. Once the information is in the wiki, it can be restructured later. So long as the information is there, it will be searchable (and hence useful).

Hmmm, that’s a bit more than the 10 they wanted. But it’s a large portion of my regular toolkit. Hopefully there’s something useful for other people in there as well…

But I’ve just seen multitail. It splits the screen and lets you follow as many log files as you like. Very handy. And it can nicely colorise the log entries if it recognises the format.

But what’s really useful is the tip in the first comment. It mentions an obscure crontab feature: @reboot. This will let you, as a user, execute a script when the machine boots up. This is dead handy, as it means that your application can be automatically restarted on server boot without having to bother the sysadmins.

More info:

• Vixie cron
• Vixie cron’s @reboot