Copyright © 1997-2013,2014 by Thomas E. Dickey


As of August 2014, I have nearly 2000 scripts in my bin-directory, totalling more than 100,000 lines. Those are distinct from scripts which I bundle with various programs. A few are modified versions of scripts written by others. Some of the scripts may be of interest to others.


There are several general-purpose scripts:

Script to construct a gzip'd (or compress'd) tar file.
This was originally by Charles Van Gale, who was a system administrator at the Software Productivity Consortium.
I extended it to use gzip or bzip2 compression, etc.
A script that combines diffstat and makepatch.
script to show which symbols are exports from object files
display all external symbols from a collection of object files
run "make", redirecting output to make.out.
script (originally by Johan Vromans) used for making patch-files.
I have modified it to sort the old/new lists to avoid confusing '/' with filename stuff.
like which, but provides the dual use of showing the path and showing details about the arguments. The conflict program is related.
run a command, redirecting output to run.out.


The original intent of this page was to provide sample scripts for building programs. Since then, I have written scripts for routine builds of the programs which I develop, as well as for managing releases and updating this website.

These are some of the scripts that I use in configuring, building and saving the logfiles from building programs on multiple platforms. A complete set of configure- and make-logs is useful for bug reporting.

Each program has its own set of build-scripts. Sample scripts for the larger programs are included in the download.


Build the program (within its working directory), with the most common configuration(s).


Repeat the build-XXX script for a given program, using different compilers and/or warning levels.


Build a given program, use the options from the corresponding all-opts-XXX script, one at a time, to build the program.


These remove the files from a build within the given program's working directory.


I use these scripts to save logfiles after doing a build. They all assume that there is a parallel directory of the same name, e.g., ../save-vile, next to the current directory. The current directory is the top of the build tree.

In particular (making them useful for bug-reports), they save the results from the configure script, along with log-files that are created using the cfg-XXX and build-XXX scripts for the corresponding programs.


These scripts are for more specialized uses.

remake an object file, reporting differences. The reference (first compile) is saved in the OBJ subdirectory.
Like path, show information about the user's CLASSPATH environment variable (which controls linking and loading of Java classes.

If no arguments given, this script displays the names of the directories in the class-path. If argument is given, it is assumed to be either a class name (e.g., "String"), or a jar-file.

All matching names are displayed; the first is the one that will be loaded.

Options (arguments beginning with "-") are passed to 'ls'.

Process one or more patch files, using diffstat's -C (color) option to markup the files (with SGR). We want to modify those so they all use reverse-video (since colored text is too hard to read), and produce html. To make the result a little more flexible, use the diffstat.css stylesheet.

The script expects one of two parameter conventions:

  1. patch-file, simply process with diffstat

  2. two directories as parameters, to pass those to diffstat using -S/-D

Search for patterns that (might be) broken defines
Search for patterns that (might be) casts.
Search for patterns that might be dates.
Search for patterns that (might be) ifdefs.
Search for patterns that (might be) K&R function declarations.
Search for patterns that (might be) numbers.
Edit the output of ldd for the given parameters, yielding only the absolute pathnames.
I use this script with less to remove temporary files.
I use this script with less to open special files.
Displays information about the user's LD_LIBRARY_PATH environment variable (which controls linking and loading of dynamic libraries.

If no arguments given, this script displays the names of the directories in the library-path. If argument is given, it is assumed to be a library name (e.g., "c" for -lc). All matching names are displayed; the first is the one that will be loaded.

Options (arguments beginning with "-") are passed to 'ls'.

Construct a manifest from the RCS description lines for the selected (symbolic) version. The script assumes that the following files are automatically generated from scripts:

MANIFEST – from this script
configure – from autoconf (, aclocal.m4)
config.h – from configure

Other files are all managed via RCS, and are present in a release only if they have had symbolic revisions added for that release.

Compares the elements of an archive file, showing which are different or missing from one archive.
Run command without /usr/local in environment.
Strip leading "." from PATH to execute a command.
Strip environment, e.g., as if running in cron, and run a command.
Strip locale environment-variables, i.e., leaving only POSIX, and run a command.
Strip all terminfo/termcap variables from environment, run command.
Remove makefile target (e.g., an object file) and run make to recreate it.
Run a command with the given locale. The first parameter is the locale to use. The remaining parameters are the command to run.

Reporting Problems

If you have a machine that I've not ported to, and have problems building one of the programs that I maintain, I will require the relevant information:

A uuencoded or mime'd gzip'd/tar file is preferred, because the logfiles can be awkward to email. Mailing uncompressed log-files also has the drawback that they may be rejected on mailing lists.

Other Scripts

Here are some scripts written by others which I have modified.
In particular, those using a restrictive license (e.g., GPL) are not bundled with the others:


The scripts on this page are a small subset of my collection. I use (predictably) another script to put together the tarballs as well as creating the changelogs on this page (with the help of rcs2log).

The "RCS_BASE" comment denotes the initial check-in using my RCS wrappers. Those preserve the modification time of the file, which in some cases predates the system where I keep these files.

In a few cases (such as path), I had created the script several years before. However, when I left the Software Productivity Consortium, I did not make a copy of the RCS archive for my general-purpose scripts (unlike ded and its friends). When moving to different projects, path), is something that I need immediately; the source-controlled version tends to lag.