MacOS X ships with groff. It even includes a shell script called
vgrind which helps format and print C, C++, and other kinds of code. I find it really useful. However, it’s broken as shipped with MacOS X. Here’s a quick fix. (Updated for Tiger)
The simplest fix is to find the
tmac.vgrind file and put it in the right directory. As it is, the file exists but in the wrong place. So when it’s time to invoke troff, it isn’t found and vgrind fails.
sudo ln /usr/share/groff/tmac/tmac.vgrind /usr/share/groff/1.19.1/tmac/
That’s the simplest way to get up and going. It’s not very good on C++, though. There’s another file called
vgrindefs that tells
vgrind how to recognize the syntax of various languages. I find that FreeBSD’s
vgrindefs file is better. I recommend downloading that file and copying it to
/usr/bin/ftp -o vgrindefs \ 'http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/usr.bin/vgrind/vgrindefs.src?content-type=text/plain'
sudo cp vgrindefs /usr/share/misc
It turns out that the default paper size setting for all things
troff related is A4. If you use a4 paper, lucky you. If you don’t, then you need to change your paper size. The following bit of perl magic will edit every file named DESC in your
/usr/share/groff/1.19.1/font directories and set the papersize from a4 to ’letter'.
perl -pi -e 's/^papersize a4/papersize letter/' /usr/share/groff/1.19.1/font/*/DESC
To use vgrind, simply provide one or more code files on the command line. It spits out Postscript on standard out, meaning that you have to capture that output to a file. Then you probably want to convert it to PDF so that you can view it with Preview and print it.
I do it this way:
vgrind wtf.cc | ps2pdf - wtf.pdf
Now I can open wtf.pdf and print from Preview. Note that I used the
ps2pdf command there. That’s part of Ghostscript, which you can get easily using Fink Commander. In theory, Preview can convert Postscript to PDF, but I’ve never seen it do a credible job. It either takes forever or it just hangs.
If you’re interested, here’s an example:
This particular example illustrates a bug in GCC that I found on the gcc mailing list. I’ve duplicated this behavior on Intel Linux (Fedora Core 1), but on no other platform. FreeBSD/AMD, OpenBSD Intel, MacOS X PPC, Solaris Sparc, etc. None exhibit this floating point issue. But that’s beside the point"