Wandering Thoughts archives

My view on vi and vim (and nvi et al)

I have a confession: for all that I use it fairly often, I am a fairly basic user of vi. As such, I have a pretty unsophisticated view of what vi is; if I type 'vi' and something starts up that behaves like vi and is not too freakishly super-intelligent, I call it vi and don't think more about it, regardless of the name of the actual implementation. Unless I actively think about it, I'm only vaguely aware that there are at least two reimplementations of vi (vim and nvi), each with their own distinct additions to the original vi. I'm not generally conscious of any differences, and I'm certainly not sophisticated enough to notice any incompatibilities with 'classic vi' (which is still found on operating systems like Solaris 10).

Calling everything 'vi' is a bit sloppy of me, and no doubt confuses some people (and may irritate others). But it really is how I think about this; for my purposes, the advanced features of vim and nvi and so on are pretty much irrelevant, because all I ever use is a subset of basic vi.

(This is much the same way that I call /bin/sh 'the Bourne shell', regardless of which implementation it actually is, and I expect that all competent implementations will behave similarly enough that I can not care. If you force me to care, I will deduct points.)

Well, this isn't quite true. It turns out that there are two features of modern vi reimplementations that I really miss: multi-level undo and the ability to backspace back to a previous line. While I won't go much out of my way to get a version of vi that has them installed on a random machine (for instance, I certainly won't compile my own version), I will switch to using a version of vi that has those features if it's already there. But I still don't really pay attention to what version it is, and I still call all of them 'vi', despite this being technically incorrect.

(I actually don't know if anything but vim supports those two features.)

If I used vi intensively, this ignorance would be reasonably foolish; I could probably significantly improve things like editing code by learning the more advanced features of the vi family. But my vi usage is reasonably casual; I have other editors for more involved text editing, and most of my vi skills have basically been acquired through osmosis and other peculiar means.

(I believe that I learned a reasonable chunk of vi by going through the old BSD vi tutorial but in another editor, which sort of robbed the embedded editing exercises of their teaching power. Still, a reasonable amount of that has stuck with me, so it wasn't a total failure.)

Where vi runs into its limits

Despite the fact that I use vi a fair bit, I feel that it has definite limits that make it not my favorite editor. For me, vi's main limits are two-fold.

First, it doesn't use graphics effectively, and I believe that it can't; the core of vi, what makes it vi and not some other editor, is fundamentally screen oriented. You can make vi display graphically instead of in a terminal window, but I don't think that you can make it into a true graphical text editor without winding up with something that no longer feels like vi; the models of operation are just too different.

(I think it is hard to see this because so few people have used text editors that really effectively use graphics. It is a lot more than just using colours and highlighting text selections; the mouse and graphics become essential parts of how you edit, and vi already has how you edit very, very well settled.)

Second, GNU Emacs is better for being freakily super-intelligent about things like code indentation. Yes, you can try to wedge that sort of intelligence into vi (and people have tried), but I feel that it is a bolt-on addition and that doing so is once again pushing vi too far.

(Why GNU Emacs is much better at this is a complicated subject. In my opinion, part of it is that GNU Emacs does not have the two sorts of languages distinction that vi does, where the core is very different from the periphery. Part of it is that GNU Emacs is fundamentally built around an interaction model that permits widespread modification of its behavior, and vi is not.)

The history of Unix *dump programs

The idea of a dump program itself goes back to V6 (Research) Unix, which introduced the first, rather basic dump program. At the time, Unix had neither tar nor cpio, so dump was your only option for backups. V7 Unix introduced tar, and I have the impression that as a result dump fell out of favour for backups.

My impression is that dump really got popular in 4.x BSD. When Berkeley revised the filesystem format to create FFS (the Fast FileSystem), with things like longer file names, they had to revise dump along with all of the other programs that read the raw filesystem, but I believe that they did not really revise the tar format, which had been designed in the days of shorter file names and so on. The net result was that dump became the best and perhaps only tool for backing up your 4.x BSD system.

(The Berkeley revision of the simpler V7 dump arguments created the basic dump options and behavior that we can still recognize today, with all sorts of options for tape blocksizes and so on. Berkeley also gave us interactive restore.)

Then the Unix vendors showed up. Dump has two problems; it reads the raw filesystem, which means that it has to be modified if you tweak your filesystem format, and its output format was never created to be portable. The result was a series of mostly but not entirely compatible versions of dump in all of the various 4.x BSD derived Unixes, most importantly SunOS. In vendor Unixes derived from AT&T Unix, things were more confused; some vendors had no dump at all (the commercial Unix side of AT&T appears not to have liked either V7's dump or tar, because they went and invented cpio), while others decided that 4.x BSD dump was a good idea but they should call it by another name, such as SGI's efsdump (to match their EFS filesystem).

(At some point, Sun decided that renaming dump to ufsdump would be a good idea.)

When people started doing filesystems that were really not derived from FFS, many of them decided that a dump-style program was a good idea and that there was an obvious naming scheme for theirs. However, they often did not bother to make either the command usage or the output format look anything like traditional dump, and so we got a parade of programs like xfsdump (SGI XFS), vxdump (Veritas VxFS, available for various Unix flavours), and vdump (AdvFS).

(This list is primarily researched from the Amanda source.)

When Linux ext2 was created, energetic people decided that it too should have a dump, so they wrote one (I am not sure if they started from scratch or used the 4.x BSD code as a base). Unlike previous versions of dump, they decided to try to make a portable suite: a dump that had relatively portable output, and a restore that could read and properly deal with pretty much any 4.x BSD derived dump format. This makes the Linux dump suite pretty much a universal receiver, which is periodically very handy.