November 1999

The UNIX Programming Environment

Not too long ago I was flame-baited into a discussion (something that seems to happen far too often these days) about the UNIX environment versus IDE's on other Operating Systems and the fancier IDE's offered for UNIX, the latter of which most programmers seem to ignore. My argument was, what many non UNIX programmers and users do not know is that the UNIX environment has something unique to it that most others miss, it is much more flexible, extensible (within the environment not necessarily a language on UNIX) and fully customizable. Apparently, for some, that is a bad thing. It occurred to me, however, that many non-UNIX users probably just plain didn't know any better. No one has bothered to go into detail (in a nice way at least) to explain how some of the tools that can be obtained for a UNIX system can be used or how to customize you own environment. This column will address both of those aspects by using the classic example of the C programming language and the current most popular GNU software(s) with an additional piece about customizing the environment.

The GNU Quick List

There are a lot of things great and small that programmers can get from the GNU project to help them along the way, this column will focus on three of the most popular as an example:

  • The GNU Debugger (GDB)
  • Electric Fence
  • Checker

We will cite a simple example of perusing each one. For more information about all three of these see the GNU project.

GDB: The GNU Debugger

GDB offers up all of the power of any modern debugging tool without the glitzy (and somewhat klutzy) front end provided by other debuggers. With GDB a few of the things one can do are:

  • set debugging symbols for run-to debugging
  • watch values
  • interactively run portions of a program
  • attach to associated processes within a program

GDB is a very powerful debugging tool even when used for the most rudimentary tasks. Following is a sample session of GDB. In this example, the user simply wants to set a breakpoint at a particular function:

bash$ gdb histogram
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnulibc1"...
(gdb)
(gdb) break cleandisplay
Breakpoint 1 at 0x8048a77
(gdb) run
Breakpoint 1, 0x8048a77 in cleandisplay ()
(gdb) 

Looks simple enough and indeed it is, using GDB is not that difficult and as it is so resource unintensive it truly makes for a robust, reliable debugger.

Electric Fence

Electric fence is the first of two memory leak detection tools we will look at. While Electric Fence may not be extremely precise, it helps give the programmer an idea of where in a given program there is a memory leak which can then be further hunted down perusing GDB or checker. One thing about Electric Fence that is interesting is it is called via the compilation call. Following is a sample of running Electric Fence against a faulty program:

$ gcc -ggdb -Wall -o mybad mybad.c -lefence
$ gdb mybad
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnulibc1"...
(gdb) run
(gdb) Starting program: /home/jfink/mybad
  Electric Fence 2.0.5 Copyright (C) 1987-1995 Bruce Perens.
l: 12345
Program received signal SIGSEGV,  Segmentation fault.
char crap[5]=("welloverfive")
(gdb)

Again, pretty simple and in this case it is pretty obvious where the problem may be, but, if it were something like overloading a header file, Electric Fence may not be able to pinpoint the exact location (depending upon the implementation). Nevertheless, in many cases it can tell you exactly what you need to know or toss you in the general area.

Checker

This little memory debugging tool is very interesting. Checker basically adds code to a program to find buffer overflows and memory leaks. Instead of using gcc straightup, try a checker mixer like so:

$bash checkergcc -o myprog myprog.c

Once the program is built using checkergcc simply running the executable will show a long result of what it found, here is a sample bit of output from a checkergcc'd program:

From Checker (pid:3459): (bvh) blockbounds violations in the heap
. . .

Interesting no? A little faster than using Electric Fence and gdb together.

Just a Small Sampling

Take my word for it, those were microscopic examples of both tools in general and how those particular tools can be used. UNIX comes with the great value added feature that it is so popular there is a ton of free tools available and being made available every day.

Creating your own Environment

We have taken a peek at the tools that can be had for no cost and dumped onto any OS and used. What about UNIX itself? What exactly does UNIX inherently have that makes it so much better than say OS/2? For me personally it is a high level of consistency, yes laugh as you might but the truth is most UNIX users can gracefully switch flavors once they get over the utilities/administration hump. The differences are for the most part low level. Now, pushing that aside what else remains? A lot.

Customizing the Shell

The UNIX shell is just a fancy interpreter, it is no different than say an interactive session with Python except a shell like tcsh or pdksh can directly access the system more so than Python or other interpretive languages. Another great thing about the UNIX shell(s) as well as many interpreters and editors is the amount of customizing one can do within them. I for instance have a set of aliases for quickly building archives of project directories, certain compiler calls (for instance I have one that calls gcc and one that calls checkergcc) and several other useful aliases. The only exception to aliasing is trying to create your own language, although most intelligent UNIX users do not do so, it is quite possible to alias yourself into stupidity.

Scripting and Programming to Script and Program

Writing small scripts and programs to create other ones can most certainly be done on any platform, but it sure seems easy as heck to do on UNIX. One little favorite of mine is small Perl program that generate Makefile templates or common parts of other programs. For example, a friend of mine wrote this set of functions for interrupt catching in Perl that is just too cool. As it goes, every time I start a Perl program I used to always copy that code from my older programs which I copied and modified from his. While there is nothing wrong with that, it sure is a pain in the neck. I am also not very good at managing template files, libraries or Perl MOD's (I seem only to have this problem with Perl). So I wrote a program that automatically dumps the bare routines right into my program file(s) when I start a project. Kind of awkward - yes - but (as I always keep trying to explain to people) I do it because I like to. The same can be done in any number of different ways in any number of different programming languages. That is the great thing about UNIXish systems - it is easy.

Editors as Environments

Now, take both paragraphs from above and moosh them into an editor. VI, XVI, VIM, GVIM, Emacs and Xemacs can all do all of the above. Within those editors, you can define MACROS to auto write pieces of small snipplets and perform automatic debugging calls so on so forth and such like. While I could go on forever about the inherent power of these editors - I'll stop here.

Overall

UNIX provides a superior development environment when applied with a little know how and reading. It is not as hard as one might believe and I am a firm believer that if I can do it - well anyone can do it (just ask my friends and family, they'll vouch for that statement!).