Formal metadata: information and software
This is not really easy, so in general I recommend that people use the executable programs that I have provided. However, occasionally people need to build the programs from the source code. While I can't guarantee that this process will be simple and easy, since it depends on software that needs to be on your system already, the procedure outlined below should get you most of the way there. These instructions are intended for users of UNIX-like systems such as Solaris, AIX, IRIX, and HP-UX.
The compiler and make utility should come with your operating
system. Try running cc -v and make to
determine if these programs are already set up for you. You should
check to see whether Expat exists on your system already: look in
/usr/lib or /usr/local/lib for a file named
libexpat.so or libexpat.a and look for a file
named expat.h in /usr/include or
/usr/local/include. Likewise, Tcl/Tk may be there
already; if it isn't, you'll find it's a handy thing to have anyway.
Mktclapp is a single C program; it can be compiled with a line like
cc mktclapp.c -o mktclapp then all you have to do is
remember what directory you stored the executable in.
In the makefile Makefile.unx I've assumed that
the Expat and Tcl/Tk libraries are in /usr/local/lib
and that the mktclapp executable is in
/usr/local/bin. The makefile can be edited to reflect
your local configuration if it is different.
$ gzip -d src.tar.gz $ tar xvfo src.tar
$ cd tools/src
$ cp Makefile.unx Makefile $ vi Makefile
$ makeThis should compile most of the programs.
$ make tk
$ ln -s /something/tools/bin/mp /usr/local/bin/mp $ ln -s /something/tools/bin/cns /usr/local/bin/cns $ ln -s /something/tools/bin/err2html /usr/local/bin/err2html $ ln -s /something/tools/bin/dbfmeta /usr/local/bin/dbfmeta $ ln -s /something/tools/bin/dbfuniq /usr/local/bin/dbfuniq $ ln -s /something/tools/bin/dbfrename /usr/local/bin/dbfrename $ ln -s /something/tools/bin/shpinfo /usr/local/bin/shpinfo $ ln -s /something/tools/bin/xtme /usr/local/bin/xtme $ ln -s /something/tools/bin/tkme /usr/local/bin/tkme
This might require you to be the system administrator. If you get
errors at this step, that's probably the cause. Obviously substitute
for something the directory in which you unpacked the tools.
Also for these commands to be useful, /usr/local/bin has to
be in your PATH. If it isn't in your path, you might want
to substitute something else for /usr/local/bin, or you might
wish to put this directory into your path.
An alternative is to use shell aliases. If you're using csh, ksh, bash, or tcsh, you can put something like these lines into your login script (either.profileor.cshrc):alias mp=/something/tools/bin/mp alias cns=/something/tools/bin/cns alias xtme=/something/tools/bin/xtme alias tkme=/something/tools/bin/tkme alias err2html=/something/tools/bin/err2html alias dbfmeta=/something/tools/bin/dbfmeta alias shpinfo=/something/tools/bin/shpinfo alias dbfrename=/something/tools/bin/dbfrename alias dbfuniq=/something/tools/bin/dbfuniq
$ mp $ cnsIn each case, the program should print out a short message indicating the command-line arguments and version number. In particular, the output of mp should not be many screens full of PostScript code. If you see that, you've run a different program with the same name. That other mp is part of some mail-handling systems. You can either re-arrange your PATH or rename one of these versions of mp.
$ xtme $ tkmeXtme and Tkme will print one or two warnings indicating that it cannot find a config file and that it cannot find a help file. If you're going to be using these, look at the information given when you choose Version from the Help menu; that explains how to set your environment up so that the program can find its more-extensive help file.
As always, contact me anytime anything goes wrong. Email is easiest for me to respond to, because that gives me some time to think about the problem (pschweitzer@usgs.gov), but you can call too.