• Choose a category
• All
• Classic-Fiction

We set the permission mask on the remote system, as we did on the local one, to allow full access for the group and read access for other:

umask $UMASK ;

The package archive file is already resident in the build directory, so we change to that directory, exiting with an error if cd fails:

cd $builddir || exit 1 ;

Next, we remove any old archive tree. We use an absolute path for rm because these commands are executed in the context of an interactive shell, and some sites have that command aliased to include the interactive option, -i:

/bin/rm -rf $builddir/$package ;

Builds sometimes have to be redone with changes to compilers and/or compilation options, so the recursive removal is essential to ensure that we start with a clean distribution. The -f option on the rm command silences any complaints about a nonexistent directory tree.

A recursive file-tree removal is a dangerous action and a target for attack. Because package was obtained from a trusted basename command, we can be confident that it contains no slashes, and thus, can refer only to the current directory. Adding $builddir/ to the argument of rm offers a small margin of safety, but not much, since either builddir or package could still be set to a dot, meaning the current directory.

The situation really reduces to a matter of trust, and there does not appear to be much else that we can do to protect you, other than warn of the danger. Certainly, this program should never be executed by the root user. That could be discouraged by statements like this near the start of the script:

test "`id -u`" -eq 0 && \

error For security reasons, this program must NOT be run by root

Among all of our systems, only Sun Solaris id lacks support for the -u option, but we set PATH to find the GNU coreutils version of id first.

* * *

Tip

You should generally ignore package installation instructions that tell you to build and install software under the root account: there are extremely few packages that require such privileges, and even then, only the installation step should need root access.

* * *

Next, we unpack the archive:

$PAR $parbaselocal ;

It is important to realize that $PAR is expanded on the initiating host, but run on the remote host. In particular, we have assumed that tar is the GNU version that supports the -j and -z options, and that unzip and jar are available. Each user of this script is expected to have shell startup files appropriately set on each remote host to ensure that these programs can be found. We cannot supply fixed paths to these programs because the paths may be different on each remote host.

If the archive was copied to the remote host, then parbaselocal and parbase have identical values, and since the package archive file is no longer needed on the remote host, we remove it:

test "$parbase" = "$parbaselocal" && /bin/rm -f $parbase ;

We are ready to change to the package directory and start the build. For software packages that follow the widely used GNU Project conventions, that directory is the top-level package directory. Unfortunately, some packages bury the build directory deeper in the file-tree, among them, the widely used Tcl and Tk tools for scripting and fast window-system interface construction. The command-line —cd option supplies a relative path to the build directory that is saved in CONFIGUREDIR, overriding its default value of dot (the current directory). We therefore need both the package variable and the CONFIGUREDIR variable to change to the build directory, and if that fails, we exit with an error:

cd $package/$CONFIGUREDIR || exit 1 ;

Many packages now come with configure scripts, so we test for one, and if it is found, we execute it with any additional environment variables supplied by envfile. We also pass on any additional flags supplied by a —configure option. Most packages do not require such flags, but some of the more complex ones often do:

test -f configure && \

chmod