"Linux Gazette...making Linux just a little more fun!"

Welcome to The Linux Weekend Mechanic!

Published in the June 1997 Edition of the Linux Gazette

Copyright (c) 1997 John M. Fisk <fiskjm@ctrvax.vanderbilt.edu>
The Linux Gazette is Copyright(c) 1997 Specialized Systems Consultants Inc.

Time To Become... The Linux Weekend Mechanic!

You've made it to the weekend and things have finally slowed down. You crawl outa bed, bag the shave 'n shower 'cause it's Saturday, grab that much needed cup of caffeine (your favorite alkaloid), and shuffle down the hall to the den. It's time to fire up the Linux box, break out the trusty 'ol Snap-On's, pop the hood, jack 'er up, and do a bit of overhauling!

Table of Contents

• Welcome to the June 1997 Weekend Mechanic!
• Wallpapering with XV: A Followup
• VIM Programming Perks
• Closing Up The Shop

Welcome to the June 1997 Weekend Mechanic!

Hey, c'mon in!

Thanks for dropping by! How y'all been doing?

So... everyone survive the semester?! I just finished taking my last final a day or so ago AND managed to find work (with the folks in Biomedical Informatics at Vanderbilt Univ. Medical Center :-) within 24 hours of finishing up. PHEW!! Nice to be done.

Anyway, I'm going to apologize for the potentially "dry" topics in this month's WM. I've not been doing much besides programming, cramming, and making occasional trips to the 'fridge, restroom, and bedroom (pretty much in that order...). I ended up doing a fair amount of programming for a couple classes and got VERY acquainted with a number of the programming tools available under Linux -- VIM, ctags, xxgdb, ddd, and so forth. Since this is what I've been doing of late, I thought that this might be an appropriate topic. The proviso is that you understand that you take this strictly as a novice's introduction to a couple of these tools.

How's that for being wishywashy... :-)

Anyway, I've found a few useful things along the way and thought someone might enjoy my sharing them.

Also, I want to continue to thank all of you who've taken the time to write and offer comments and suggestions. Believe me, I don't claim extensive knowledge or expertise in most of the things I write about -- these are mostly discoveries and ideas that I've hit upon and am sharing in the hopes that they might be helpful. I welcome corrections, clarifications, suggestions, and enhancements! Several of you wrote in with regards to wallpapering using XV which I'll be sharing below.

Well, thanks again for stopping by! Hope you enjoy :-)

John M. Fisk
Nashville, TN
Thursday, 8 May 1997

Wallpapering with XV: A Followup

My sincerest thanks to Brent Olson, Peter Haas, and Bill Lash for taking the time to write and offer these suggestions. I tried tinkering around with a few of these suggestions and they work like a champ! Here they are:

---

Date: Wed, 02 Apr 1997 09:24:59 -0800
From: Brent Olson <brent@primus.com>
To: fiskjm@ctrvax.Vanderbilt.Edu
Subject: re: reducing the colors in a background

You've probably already been told this, but in the LG article relating to reducing the number of colours used in the background, there is no need to convert the picture first. It can be done on the fly:

xv -root -quit -maxpect -ncols 16 filename.gif

Works great on my lousy 8-bit NCD display at work.

Brent Olson
mailto: brent@primus.com

---

Date: Tue, 08 Apr 1997 08:42:01 +0200 (MET DST)
From: hap@adv.magwien.gv.at
To: fiskjm@ctrvax.Vanderbilt.Edu
Subject: xv - interesting options

There are another two interesting options of xv:

-random filepattern   selects a random picture of given given filepattern 
-ncols #colors        to limit number of used colors

An example out of my .fvwm2rc95:

xv -quit -root -ncols 16 -random /var/X11R6/lib/xinit/pics/*.gif

Regards, Peter

-- 
 (~._.~)    From the keyboard of Peter Haas (hap@adv.magwien.gv.at)
 _( Y )_    Located at MA14-ADV, Rathausstr.1, A-1082 Wien, Austria
()_~*~_()   Phone +43-1-4000/91126   FAX +43-1-4000/7141
 (_)-(_)    "Big iron" division

---

From lash@tellabs.com Thu Apr 24 21:20:39 1997
Date: Thu, 24 Apr 1997 17:52:27 -0500
From: Bill Lash <lash@tellabs.com>
To: fiskjm@ctrvax.Vanderbilt.Edu
Subject: Limiting colors with XV

John,

I read your article on wallpapering with XV. You suggest choosing images with a limited number of colors. You go on to suggest several options, but you missed a simple solution. You can tell XV how many colors to use in displaying the picture using the -ncols option.

At work, I usually run with a background of 100 colors on an 8-bit pseudocolor display with the following command line:

xv -root -quit -max -rmode 5 -ncols 100 image.gif

Bill Lash
lash@tellabs.com

Again, guys, thanks for writing. Happy wallpapering!

John

VIM Programming Perks

Well, as I mentioned above, I ended up spending a good deal of time programming this semester. Our software engineering team designed and coded a simple FORTRAN 77 spell checker in C++. Thing was, the analysis and design phase consumed 11 of the 14 weeks of the semester AND it was done using Structured Analysis. Problem was, we had decided to code this thing in C++ and so ended up almost completely redesigning it using OO Analysis and Design during the last couple weeks (when we were supposed to be doing nothing but coding :-).

Anyway, this meant a LOT of late nights -- integrating everyone's code got a bit hairy, since none of us had much experience with team coding. I was mighty thankful for the development tools under Linux. I spent the better part of 13 hours one Saturday debugging our first effort at integrating the code -- chasing down Segmentation Faults and infinite loops :-)

Ahhh... the stuff of programming... :-)

Along the way I learned a few interesting and nifty things about the VIM editor, which has been my 'ol workhorse editor for the past couple years now. I wanted to give this thing another plug as I think it's one of the best things since sliced bread. I'll admit that the emacsen, including the venerable XEmacs, are a LOT more powerful and full featured. But, having developed the finger memory for the "one-key-vi-commands" I've found that I can get a lot of work done fast. I'd like to 'tip the hat at this point to Jesper Pedersen and Larry Ayers both of whom have written very nice articles on emacs and XEmacs in past issues of the LG and the Linux Journal. I'd encourage anyone interested in these to have a look at these articles. I'll also be mentioning XEmacs below and give you a screen shot of the latest 19.15 iteration.

Anyway, here's a few (hopefully) interesting notes and ideas for using the VIM editor!

GVIM -- Going Graphical!

I recently downloaded and compiled the latest beta version of VIM which is version 5.0e. If you have the Motif development libraries you can compile VIM with a Motif interface -- gvim. This rascal is pretty good sized and not exactly fleet of foot. It's a bit slow getting out of the gate on startup and so it's probably prudent to heed the Makefile suggestions and compile separate versions of VIM both with and without X support. I tried starting versions of vim (at the console) compiled with and without X support and the extra X baggage definitely slows things down.

A bit later on in this article I've provided several screen dumps of gvim as well as a couple other editors and the xxgdb and ddd debuggers. If you're the impatient or curious type, please feel free to jump ahead and have a look. Also, I've included a couple links for additional information.

Actually, VIM has provided a GUI since around version 4.0. I've been using this for some time now and find that it adds a several enhancements over vim at the console:

• it has a reasonably handsome and functional scrollbar
• mouse support is automatic and allows VERY easy cursor movement, text highlighting, and cut-and-paste operations
• it provides a customizable menubar
• it intelligently understands the movement keys -- Home, End, Page Up, Page Down, arrow keys -- even in insert mode
• depending on how you have your .Xmodmap set up, it will intelligently handle Back Space, and Delete keys AND you can delete backwards over multiple lines!

The Big News: Syntax Highlighting!

(...this is like the guy hawking the $2.99 Ginzu knives, "they slice, they dice, here... I can cut through a cinder block wall, this lamp post, a street sign, AND the hood of this guy's car and never loose an edge! But that's not all... if you act right now...")

You get the point.

What I was going to say was that vim also provides syntax highlighting for shell scripts (VERY COOL!), makefiles, and the VIM help files (which you'll see here in just a bit). All in all, this is pretty nice. I've been tinkering around with this a bit and am really starting to like it. Be aware that the highlighting isn't quite as "intelligent" as with something like XEmacs -- it doesn't provide the same degree of sophistication. Still, it's very good and, being an order of magnitude smaller and a good deal more nimble, it's well worth trying.

VIM installed the support files for syntax highlighting (at least on my system) under /usr/local/share/vim/syntax. There are individual files for the various languages and file types as well as the syntax.vim file that does a lot of the basic coordination. You can tinker around with these to get the "look-n-feel" that you want. Keep in mind that to get automatic syntax highlighting you'll need to add something like this to your ~/.vimrc or ~/.gvimrc file:

" Enable automatic color syntax highlighting on startup
source /usr/local/share/vim/syntax/syntax.vim

I have to admit that I wrestled with this for longer than I should have trying to figure out how this was done. Hopefully, this will save you some trouble :-)

Again, I've included screen dumps below so that you can see what this looks like. In addition, the VIM home page has a couple nice screen shots that you might want to have a look at. I should add that syntax highlighting is individually configurable for the console and the X version. Now, before you go dashing off and "rushing in where angels fear to tread..." you will probably want to have a look at the help files or documentation -- it gives some basic guidelines for customizing this stuff.

And speaking of which...

Help is on the way!

And what's more, all of this is provided on-line. In command mode you simply type in:

:help

"...use the Source, Luke"

The help system is set up in a hypertext fashion. If you've enabled automatic syntax highlighting then even the help system is colorized. To follow a link you can either hit the letter "g" and then single click with the mouse on a topic, or you can move the cursor to that topic and hit "Ctrl-]" (hold down the control key and hit the left square bracket key -- "]"). To get back up to where you started, hit "Ctrl-t".

It's that simple :-)

IMHO, this is one of the most laudable features of VIM. The documentation is generally well written and reasonable understandable. It is VERY thorough and, since it's available from within the editor, provides a high level of usability. It also provides a "Tips" section as well as numerous "How Do I...?" sections. It's Must Reading...

Ask "The Man!"

:!man test

To be honest, I've found that this works a LOT better at the console than under gvim, although the exact reason eludes me. Under gvim, I get the following error:

WARNING! Terminal is not fully functional

My suspicion is that it has to do with the termcap stuff built into the editor. Forward movement down the manual page (hitting the space bar) is reasonable smooth, but backward movement is very jerky and screen redraws are incomplete. Still, if you can live with that you'll find this VERY convenient.

TAG, You're It!

Basically what tags allow you to do is find that point at which a function or variable is declared. For example, suppose you ran across the following snippet of code:

    HashTable HTbl;
    HTbl.Load("hash.dat");
    found = HTbl.Lookup(buf);
    .
    .
    .

    HTbl.Load("hash.dat");
         ^

This is seriously cool!

When you're ready to move back to your original location, hit "Ctrl-t" (which moves you back up the tag stack). I've been using Exuberant Ctags, version 1.5, by Darren Hiebert for the past little bit now and really like this a lot. As the name implies, it does a pretty thorough job of scouring your source files for all sorts of useful stuff -- function declarations, typedefs, enum's, variable declarations, macro definitions, enum/struct/union tags, external function prototypes, and so forth. It continues on in the time honored tradition of providing a bazillion options, but not to fear: it's default behavior is sane and savvy and provides a very nice OOBE*.

*(Out Of Box Experience)

You should be able to find Darren's Exuberant Ctags (ctags-1.5.tar.gz was the most recent version on sunsite and its mirrors at the time of writing) at any sunsite mirror. I happened across it in the Incoming directory. You'll probably find is somewhere under the /devel subdirectory now. If you get stuck and really can't find it, drop me a note and I'll see what I can do to help. This one is definitely worth having.

Oh, BTW, using ctags is child's play: simple give it the list of files that you want it to search through and it'll create a "tags" file in your current directory. Usually, this is something like:

ctags *.cc *.h

ctags *.c *.h

:ta isAlpha

Using the Real Windows...

To pop up a second (or third, or fourth...) window with a specific file, simply use something like:

:split ctags.README

:split

Ctrl-w j (hold down control and hit "w", then hit j)
Ctrl-w k (hold down control and hit "w", then hit k)

Resizing the windows is nicely handled using the mouse: simply click anywhere on the dividing bar between the two windows and drag the bar to whatever size you want. This is really handy if you are using one file as an occasional reference but want to edit in a full window. You can resize the reference file down to a single line when it's not needed.

Again, there's a lot more information in the online help about using multiple windows.

SHHHHHhhhh.....! Let Me Tell You A Secret!

Ready...? (look furtively around with squinty, shifty gaze...)

(... the clock ticks loudly in the other room, somewhere in the distance a dog barks, the room falls into a stifling hush...)

He clears his throat loudly and in a harsh whisper exclaims...

"The "%" sign expands to the current buffer's filename!"

Phew! Glad that's over... :-)

Yup, with this little tidbit you can do all sorts of cool and groovy things. Like what you ask...? (you knew this was coming, didn't you... :-)

RCS checkin and checkout

I won't go into using RCS for version control except to say that doing checkin's and checkout's from within VIM is VERY easily accomplished doing something like:

    :w!
    :!ci -l %
    :e %
    

So what's going on...? Well, the first line writes the current buffer to file, the real good stuff happens on the second line in which you use the RCS ci to checkin and lock the current file. And finally, since the checkin process may have altered the file if you've included "Header", "Id", "Log", etc., reloads the file with the new RCS information (if any).

Now, for all you VIM jockeys out there, the handy thing to do is use "map" to bind this sequence to a single keystroke. I've bound this to Alt-r and it makes the whole operation smooth and painless.

Printing that 'ol file

This is another favorite trick. To print the current file from within vim simply:

    :w!
    :!lpr %
    

what could be easier? :-)

Seriously, this is a very convenient means of getting a hard copy of your current file. The one caveat to remember is that you'll probably want to commit the contents of your current editing buffer to file before you try to print it.

I've been using the apsfilter program for last year or so and absolutely love it. It is a series of shell scripts that automate the process of printing. Basically, it uses the file command to determine the type of file to print and then invokes lpr with the appropriate print filter. As a backend, it uses the a2ps program to format ASCII into Postscript and then uses Ghostscript to do the actual printing. Now, using something like:

    lpr [filename]
    

transparently formats the file to Postscript and sends it to the printer. I've been quite pleased with this. You should be able to find this and similar programs at any of the sunsite FTP sites under the /pub/Linux/system/print (printer?, printing?) subdirectory (sorry, I'm not connected to the 'net at the moment and can't recall the exact subdirectory name off the top of my head :-).

Also, I've played with the a2ps program itself and found all sorts of cool and nifty options -- single page/double page printing, headers, boundary boxes, setting font sizes, and so forth. I particularly like being able to set the font size and header information. And, as always, IHABO*.

*(It Has A Bazillion Options)

Word Counts...

If you hit the Ctrl-g key combo, VIM prints the filename, number of line, and the current position in the file on the bottom status line. However, if you want a word or byte count, simply invoke the wc program on the file:

    :w!
    :!wc %
    

which will print out the file's line, word, and byte count.

You get the picture. Basically, any command that takes the form

command [-options] filename

:! command [-options] filename

Note that there are a couple other handy little items you might be interested in. If you want to include the contents of a file in the current buffer, OR if you want to capture the output of a command into the current buffer (for example, a directory listing), then use:

:r a2ps.README
:r! ls /usr/local/lib/sound/*.au

The first command would insert the contents of the a2ps.README file in the current buffer wherever the cursor was located; the second command would insert the output of an ls listing for the /usr/local/lib/sound/ directory. That is, you can use this second form for any command that prints its output to standard out.

This discussion leads directly into the question of spell checking the current buffer. And the answer that I've got is that I haven't found an easy or convenient way to do this. I ran across a key mapping definition a while ago that basically copied the current file to the /tmp directory, ran ispell on this file, and then copied this file back over the original. It worked, but it was clunky. I've also tried, with some modest success, to do something like:

:w!
:! ispell %
:e %

Screen too small:  need at least 10 lines
Can't deal with non-interactive use yet.

1 returned

Ideas anyone?

Running Make!

I've found that gvim, in particular, provides excellent support for make. Basically, once you have a working makefile, simply invoke it using:

:make

:cn

And So Forth...

Phew! How's everyone doing...? Still hanging in there? I'm almost done here so stay tuned. :-)

There are LOTS of other rather nifty features that vim/gvim provides. The adventurous will find all sorts of goodies to experiment with in the online documentation. Let me call your attention to just a few more and we'll wrap this up and have a look at some screen shots!

Unlimited Undo

The way vim is (generally) configured, it keeps track of ALL the editing changes you've made to a file. So, after an hour's worth of editing, should you decide that War And Peace really didn't need a another chapter, then you can back out of all your changes by repeatedly hitting the "u" key. This reverses the changes you've made to the file in a sequential fashion. Now for a major back out, you'd have done well to check the original file in under RCS and then retrieve this version if you decide not to keep your current changes. Still, you can back all the way out if you don't mind hitting "u" for a while... :-)

Compressed File Support

One of the other nice things introduced into vim around version 4.0 was support for editing compressed files. Essentially, what this involves is transparent uncompressing of the file upon the start of editing and recompressing the file when vim terminates. This is quite helpful as it allows you to save a LOT of space if you work with a large number of text files that can be compressed. You may also be aware of the fact that the pager "less" has this support built in and so do most all of the "emacsen".

The support for this is configured in using an entry in your ~/.vimrc or ~/.gvimrc. I use the stock vimrc example that comes with the distribution:

" Enable editing of gzipped files
"    read: set binary mode before reading the file
"          uncompress text in buffer after reading
"   write: compress file after writing
"  append: uncompress file, append, compress file
autocmd BufReadPre,FileReadPre      *.gz set bin
autocmd BufReadPost,FileReadPost    *.gz '[,']!gunzip
autocmd BufReadPost,FileReadPost    *.gz set nobin

autocmd BufWritePost,FileWritePost  *.gz !mv <afile> <afile>r
autocmd BufWritePost,FileWritePost  *.gz !gzip <afile>r

autocmd FileAppendPre           *.gz !gunzip <afile>
autocmd FileAppendPre           *.gz !mv <afile>r <afile>
autocmd FileAppendPost          *.gz !mv <afile> <afile>r
autocmd FileAppendPost          *.gz !gzip <afile>r

set ai                " turn auto indenting on
set bs=2              " allow backspacing over everything in insert mode
set noet              " don't expand tabs into spaces
set nowrap            " disable line wrapping
set ruler             " display row,col ruler
set showmatch         " show matching delimiter for parentheses, braces, etc
set ts=4              " set tab stop width to 4
set tw=78             " always limit the width of text to 78
set sw=4              " set the shift width to 4 spaces
set viminfo='20,\"50  " read/write a .viminfo file, don't store more
                      " than 50 lines of registers

:set noai

#!/bin/sh
#
# fdformt.sh   formats 1.44 HD floppies in the fd0 drive
#
# Author:      John M. Fisk <ctrvax.vanderbilt.edu>
# Date:        6 May 1997

FORMAT_CMD="superformat -v 3 "
FLOPPY_DEV="dev/fd0"

while : ; do
    echo -n "Format floppy [y,n]? "
    read yesno
    if [ "yesno" = "y" -o "yesno" = "Y" ]; then
        echo -n "Insert floppy and hit any key to continue..."
        read junk
        ${FORMAT_CMD} ${FLOPPY_DEV}
    else
        break
    fi
done