UnixTools

David Jeske -- Scott Roland

UnixTools was developed by Scott Roland and I. It is a Unix encap system which we found to be of significant use while administering UNIX packages at work in our spare time. The main goals of UnixTools are:

To allow multiple packages to be installed, and have the user easily choose which are part of his environment.
To allow multiple versions of the same package, again to be selected by the user.
To allow logical names for packages like 'mail-latest'.
To have package-sets which the administrator and user can define to allow multiple packages to be grouped together.
To automatically notify the user when new packages or new versions of packages are available.
To automatically notify the user when one of his packages or package sets are updated or changed.
To provide a convinent web and text interface for listing the available packages.

We largly succeded on all of these goals.

As UnixTools is designed to work with existing UNIX software, it is largly a process for compiling (when necessary), installing, documenting, and organizing UNIX software. There are custom tools involved in parts of the system, here I'll summarize each one of them:

add-export.sh - This is the core of the UnixTools system. A user of UnixTools need only "source" this script in one of his startup files. This script will look at his .unixtools configuration and, depending on his shell, decide how and what to add to his PATH or environment.
ut-cgi - The cgi-bin tools for browsing the installed packages and their install-notes/docs/etc.
pkglink - a program which helps you link into a shared tree (bin,lib,man,etc.). Shared trees are discouraged in UnixTools because they defeat some of the goals, however they are convinent for people who use inferior shells.

More details

add-export.sh really performs all the magic. It looks at your package config file, and figures out what packages should be in your environment. Your package include file can contain package names, or package-set names. When it figures out what you want in your environment, it makes a record in it's cache file (also in your home directory) of what you last had in your environment. This way it can keep track of, and notify you of, any changes to your package environment. After it does this, it uses a shell dependent method to add the package binary files to your shell's environment. The preferred method is direct hash table insertion. Nicer shells walk through your list of paths and generate a cache of what is available in your path directories. Thus commands like "rehash". Some of them, like zsh, will let you manually insert entries into this hash table. Because the path space quickly becomes cluttered in an encap environment, and because we want to be able to have more flexibility in binding packages to shell command names, the preferred method of adding to someones environment is to directly add into their shell's hash table. However if they are using an inferior shell, or if they would prefer the sanity of just having everything in their path, they can opt to have the relevant package directories added to their paths. into the "path hash table".

Download some scripts

ut.tar.gz
"external" and "internal" were our high-level orginizations of whether tools were written inside the company or not. In the future I think I would opt to avoid this and instead just include information like this inside the encap-desc. Below are some more path descriptions:

./external/export/etc/add-export.*

The magic of starting up the unixtools environment happens here. Users would source the appropriate script for their shell and make a .unixtools-prefs file if they wanted to custom configure their interactive environment.

./external/src//encap-info

We kept all the source for packages around in this source tree, and inside the source directory we recorded information about the compiles into the encap-info files. You can take a look at the example encap-info files for the packages we had installed.

./{external|internal}/export

this was the backward compatible directory which contaned both the 'startup scripts' in etc, and a basic bin directory with basic tools for those who just wanted to add one directory to their path.

./{external|internal}/tools

This is where we put the compiled packages themselves. As you can see from the encap-info descriptions of the builds, we separated platform dependent and platform dependent files and the add-export script magically setup stuff accordingly.

./{external|internal}/tools/<package>/encap-desc

This is where we put the human readable 'description' of the package. This is how the cgi-bin package browser, and the auto-notify stuff in add-export would explain what the package was for.

David W. Jeske (jeske@chat.net)