Copyright © 1997-2017,2019 by Thomas E. Dickey
As of August 2014, I had nearly 2000 scripts in my bin-directory, totalling more than 100,000 lines. The list continues to grow (see screenshot). 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:
Construct a gzip'd (or compress'd) tar file.
unarchive, it reverses the process.
archivewas originally written by Charles Van Gale, a system administrator at the Software Productivity Consortium in 1989 or 1990. I extended it to make the resulting tarball have a timestamp matching the newest file (using cpd), as well as using gzip or bzip2 compression:
A script that combines diffstat and makepatch.
script to show which symbols are exported from a collection of object files
display all external symbols used by a collection of object files
run "make", redirecting output to
If linked or renamed to
make-log, it writes to
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.
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
If linked or renamed to
run-log, it writes to
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. I use
scripts named for the various programs (
in the following sections).
Though the oldest of these scripts (for saving build-logs from dbmalloc) dates back to 1995, they have evolved in stages. Initially, I would do test-builds and, after verifying the results, possibly discard the logs. However, for several years I have collected the logs, adding them to my source repository to compare.
As of January 2016, I have 5488 log-files (with 383 marked to denote systems where I can no longer build). Some builds produce multiple log-files, and I have build-scripts for about 50 programs. There are also a lot of machines to build with.
Build the program (within its working directory), with the most common configuration(s). As part of the process, install and uninstall the program (to a location in the build-tree).
build-XXXscript for a given program, using different compilers and/or warning levels. Depending on the platform, this may execute other scripts to build “.deb” (Debian), RPM packages, NSIS installers or Solaris packages.
Build a given program, use the options from the corresponding
all-opts-XXXscript, 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
build-XXXscripts for the corresponding programs.
Where possible, I parameterized these scripts to make a reusable core. These scripts provide the reusable parts:
Along with the build-scripts, I use wrappers for
gcc to turn on compiler warnings, as well as
scripts for other compilers. They are included in the
build-scripts, since that is where they are most used.
This provides what should be the minimal options for
gccto ensure that C functions are prototyped. I added it in 1995 at the same time that I added
gcc-strict. Before that, I was likely to just edit the makefile, not thinking that it would be simpler to make a wrapper script.
This script adds
gccoptions to compile for 64-bits. When I added it in 2009, it was still common to have compilers on a nominally 64-bit platform such as Solaris default to compiling 32-bit code.
I made this script, incorporating some posting by Fergus Henderson, e.g., this one to gnu.gcc.help from 1994.
Later, I was told about the gcc "fortify" option. Rather than modify the options in
gcc-strict, I added this script.
Configure script wrappers containing configure options for specific programs are (usually) named for those programs, e.g.,
I am able to cross-compile to MinGW on several machines. There is no consensus on what directories those cross-compilers use. These scripts help:
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:
configure, with options
config.cache(if available—"new" versions of autoconf suppress this, but for example lynx preserves this file).
make, with options
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.
These scripts are for more specialized uses.
remake an object file, reporting differences. The reference (first compile) is saved in the
I use this script when making structural changes to a C program that “should not” change its content, e.g., converting from K&R C or changing comments/formatting.
Like Regress, I use this for checking changes to manual page formatting.
Scan a directory tree, looking for nroff (man/ms) files, to check their syntax as well as verify that their macros are consistent.
checknrwere portable and handled manpages, it would be useful. This started as a wrapper for
groff's checks, but has grown a lot.
Like path, show information about the user's
CLASSPATHenvironment 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'.
Use ncurses' infocmp to compare two terminfo files. Its output is close, but is not sorted in a predictable manner that would allow
diff'ing output from different comparisons.
Scan directory-tree or file(s) counting nroff files, adjusting for comments.
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
The script expects one of two parameter conventions:
patch-file, simply process with
two directories as parameters, to pass those to
Search for patterns that (might be) broken defines
Find the X bitmap font-files which are used in xterm/uxterm app-defaults files, and for some systems (where the packaging system is useful) followup with the packages containing those files.
See my answer using this script.
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.
tidyto indent one or more HTML files, optionally showing the differences made (
-v) and with dry-run (
perltidyto indent one or more Perl files, optionally showing the differences made (
-v) and with dry-run (
Format the output of
stty -ainto a single column, allowing
diffto show just the single feature(s) which may change.
Edit the output of
lddfor 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_PATHenvironment 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 (configure.in, 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
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
maketo recreate it.
For each "psf" font listed in /usr/share/consolefonts, make a report showing which ISO-8859-x variants are covered, as well as the line-drawing used by ncurses.
Analyze one or more terminfo descriptions to get some useful statistics. This assumes that you have tic, toe and infocmp.
For a given package, ask the question: what packages satisfy its dependencies, and is there a “provides” which can be used as an alias for those.
Strips ANSI escape sequences and reduces backspace/overstrikes.
The script uses POSIX sed, which means that only BREs (Basic Regular Expressions) are permitted.
I have tested this with FreeBSD 10, OpenBSD 5.3, Solaris 10 as well as Debian 6 and later:
Here are two examples, using "cat -v" to make the nonprinting characters visible:
Read the database printed by “dircolors -p” and show the different patterns with the indicated color by (as done by GNU ls) using hardcoded SGR sequences.
The output can be viewed with “less -R”.
See my answer using this script.
See these alternatives which use the
Successively load and display console fonts using either showconsolefonts or a grid for the different ISO-8859-x locale settings. Like the ncurses test-programs, provide for reading a key for single-stepping or proceeding with a time-delay. It does not use the perl Curses module, since that would interfere with sending raw bytes to the screen.
Sort the list of parameters as if they are filenames containing a version. I use this to sort the names of tar-balls for my programs in builds as well as website maintenance.
By the way, I noticed a comment in remove the low version number of file indicating that GNU
lshas a similar feature. However, the rules for parsing the version are a little different, and in my script the version number follows the program name.
Recursively touch (change timestamps) on directories to reflect the newest file inside the directory. I use this for tidying up source-trees, e.g., as in the “
-t” option of archive (which uses cpd).
Here are a few links which I found when looking for comparable scripts or programs:
Oddly, most applications in this area simply update the directories (and files) to the current date.
Run a command with the given locale. The first parameter is the locale to use. The remaining parameters are the command to run.
I wrote these scripts to provide a way to export information from my RCS archives to Git, starting in July 2016 (see Git exports):
Upload a git bundle to github in my "testing" repository. That can be renamed, to provide a "readonly" snapshot.
For a given project, use
release2git -Rto find its labeled releases, and generate a manifest-file for each of these. Discount the first line, and compare successive files to identify changes from one release to the next.
Initial script, using my modifications to
rcs-fast-exportto export snapshots of mawk.
Rather than attempt to export RCS archive to Git using
rcs-fast-export.rb(and have to do this repeatedly), analyze an RCS archive and apply release snapshots to a Git-ball incrementally. That loses most metadata (such as the individual file timestamps, comments, etc), but should work even with my larger archives.
release2gitto obtain a list of versions and files for a given cutoff date, and apply a label to that based on the cutoff date.
I wrote these scripts to support generating map- and sym-files for ncurses6 symbol versioning:
Count symbol usage for the given executables, and summarize their usage with categories for these types:
- ncurses (if using ncurses extension)
- curses (if not using ncurses extension)
Compare two “.map” files, generate a report showing the number of symbols added, deleted or renamed. A “renamed” symbol is one whose scope differs or is in a different version (the numeric plus “.” part on the end of the label).
Optionally show only the number of symbols changed.
Extract symbols from a given patch-date for dialog.
Inspect the given (build-)tree for libraries and programs, determining which symbols exported by the libraries are needed by other libraries or the found programs. Print a list showing the symbols, where they are declared, and their needed status (global or local).
needed-syms, construct “.map” and “.sym” files for the current build-tree's configuration of ncurses.
The “.sym” files are trivial – a comment header telling what options were used to generate the configuration, and a sorted list of symbols.
The “.map” files require special effort, because they are constructed as a series of version-nodes. So... to generate a new one requires us to read the existing “.map” file to relate the symbols' version and scope to the previous version.
To allow for symbols being in termlib/ticlib/ncurses, always generate the names as if they were in the separate library. Doing this allows splitting the map-file into parts and (possibly) making it work with Solaris, which does not accept a map-file declaring a symbol not in the library.
Successively build ncurses for release-dates with several combinations of configure options and merge the result to generate usable map- and sym-files.
Read one or more “.map” files, generate a report showing
- scope (global or local)
Optionally show only the number of symbols in each scope.
Here are some scripts written by others which I have
In particular, those using a restrictive license (e.g., GPL) are not bundled with the others:
This is a slightly-modified copy of
altcharsby John H. Dubois III (from here). The original script carries forward a documentation error from AT&T, for the lantern pseudo-graphics character which was fixed in ncurses in 1997 as a result of work on lynx.
Starting in 2000 (for ncurses Ada95 binding), I have modified this script to make the generated HTML validate, as well as to use CSS. (The script is originally from gnat, but unmaintained).
linklint, but (see this) it has been unmaintained since around 2001. For example, see the Debian bug-reporting system. As of early 2016, I have fixed most of the problems which affect me:
- flush stderr/stdout, so I can pipe result inside vile
%20's back to spaces to check for actual files with spaces
- <a>-tags are not the only things that can have
This is an improved version of Earl Hood's
man2htmlPerl script (see my expanded page on the topic).
I modified this script in 2003 (it was originally from emacs, but unmaintained):
- to allow for symbolic links to RCS directories, e.g., for
- to avoid using bogus hostname for authors
This is a wrapper for
rpm2cpiowhich makes it easier to use. There actually is more than one script named “
unrpm” — this is the best-known, and was seen in a posting to the fedora-legacy mailing list in 2004, stating that it came from the
fedora-rpmdevtoolspackage. According to the package's changelog, it was removed in 2005.
This is useful for xterm testing, found in Debian #588785 (from
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.