System V versus BSD UNIX

Now a days you will most likely be exposed to AT&T System V UNIX. Years ago there were dozens of different 'versions' of UNIX. At some point things started to converge to either AT&T System V (pronounced A T and T System Five) or BSD UNIX.

If you go for a job interview they might ask you things like, "How do you list all processes?" If you are using System V then the answer is "ps -ef" but it is "ps -aux" if you are using BSD UNIX.

Additionally, a lot of the System V installations have the BSD implementations of commands as well. The idea is that I might have a script that assumes BSD format commands. If I was to parse the output of ps to do a mass kill of all processes and its children then the format of the ps command matters.

If the script was written assuming the BSD version of ps and my computer was configured for System V, the script will fail. The solution, the default path might be /usr/bin but the BSD version of the commands are stored in /usr/ucb. So I could just edit the script so it finds the /usr/ucb/ps command rather than the default /usr/bin/ps.

Finally, if you are using MacOS X you are using a GUI front end to an implementation of UNIX. The UNIX is BSD UNIX. So things like "ps -ef" will not work.

So if you want to impress an interviewer who asks how to list all the processes on a UNIX machine, the answer is "If your computer is configured for System V UNIX then ps -ef will do the trick, but if /usr/ucb exists in the path before /usr/bin then ps -aux will do the trick. Additionally, if you are using MacOS X, which is BSD UNIX, then the default path will use ps -aux."

There are some obvious wrinkles to this. I'm assuming the default set up and configuration for the system. You'd impress them more if you asked which verison of UNIX and then noted, "if they are using the common configuration..."

If you want to read more of the details behind the history of UNIX, give this web site a try. Additionally, this site talks about creation of different versions of UNIX. Click on the picture at the top to see how nuts it got.

Debugging Bourne shell scripts

When most people start programming Bourne shell scripts they are VERY small. If you take over someone else's work or you have been programming shell scripts for any significant length of time, you will find something wrong in a script of thousands of lines.

Originally you might have put a few echo statements to see what was going wrong with a script. With thousands of scripts, scripts calling scripts, aliases set to scripts, system commands written as scripts, etc. it can get quite difficult to find a bug using echo statements.

The solution is to run the script with the -x flag. If you have the script starting with:

#!/bin/sh

then you can edit it to be:

#!/bin/sh -x

Or better yet, if the script is run using:

./myscript.sh

change it by using:

sh -x ./myscript.sh

Running the script with this option will let you see each line as it is executed. You will also see variables getting expanded. With this output the echo statements should be unnecessary. Try running a small script with this option and see what it outputs.

Introduction

Greetings and welcome to my geek blog.

The purpose of this blog is to create a knowledge base of programming/computer information.

I would also be open to answer questions from other people.

I have experience with:

- UNIX (AIX, Solaris, HP-UX)
- Linux (Redhat and SuSE)
- Windows
- MacOS X

I program with:

- C
- C++
- Perl
- Bourne shell
- C shell
- Java
- various assembly languages
- and many more

Check back regularly for new tips and information.