NAME
envpath - Advanced operations on path variables
SYNOPSIS
Run this script with the -help option for usage details.
DESCRIPTION
Parses the command line, modifies the specified path variable(s), and execs the remaining arguments. There are two modes, simple and advanced:
SIMPLE MODE
Simple mode presents an alternative, platform-independent syntax for specifying paths wherein the path separator is "," and environment variables can be represented as @NAME@. For example
pathmod PATH=@PATH@,/usr/ucb -- printenv PATHappends /usr/ucb to $PATH and execs printenv PATH. The -- is optional.
You can also specify prepending or appending by using += or =+ respectively:
# place /usr/ucb at the front
pathmod PATH+=/usr/ucb -- printenv PATH
# place /usr/ucb at the back
pathmod PATH=+/usr/ucb -- printenv PATHSimple mode requires only this script; it does not require Env::Path to be installed.
ADVANCED MODE
Advanced mode basically provides command-line access to the features of Env::Path (see), which must be installed. The -E flag selects the path variable to operate on and other flags specify operations on it. E.g.
pathmod -E MANPATH -A /tmp -R /usr/share/man -N -U -- man ...would take MANPATH, append /tmp to it, remove any references to /usr/share/man, remove any dirs which don't exist (-N) and remove redundant entries (-U) before running man.
CLEARCASE WINKINS
A big part of the motivation for this script was for use with ClearCase builds; if you know or care about ClearCase read on. Typically, during builds (and not just with ClearCase), pathvars such as PATH, CLASSPATH, and LD_LIBRARY_PATH must be strictly controlled. One choice is to force static values of these into the environment during the build process, another is to simply require/expect users to set their paths appropriately. Each of these can lead to subtle build errors, however, and can make it hard for new users to get up to speed if their environment must be just so.
Another possibility is to use full pathnames for everything. This is often the best way to go but can raise problems with ClearCase winkins. For example, say you're generating ascii files of some type with a binary executable you just built:
$(INCDIR)/foo.h: $(BINDIR)/foomaker $(BINDIR)/foomaker ...
The problem with this is that $(BINDIR) likely contains a platform part such as 'solaris' or 'hpux', which makes it impossible to wink in the foo.h file on other platforms even though it's ascii. This same thing could come up even with a standard utility that's in different places on different platforms.
You could modify the path on the fly:
$(INCDIR)/foo.h: $(BINDIR)/foomaker PATH=$(BINDIR):$$PATH foomaker ...
but this suffers from the same problem: since $(BINDIR) and $PATH are expanded on the command line they'll suppress winkins. Here's a solution using envpath:
$(INCDIR)/foo.h: $(BINDIR)/foomaker envpath PATH=@BINDIR@,@PATH@ foomaker ...
all we're doing is delaying the evaluation of BINDIR and PATH such that clearmake never sees anything but the literals, thus clearing the field for winkins. Of course envpath is capable of doing more than this, but the above is the reason it was written.
AUTHOR
David Boyce <dsb@world.std.com>
COPYRIGHT
Copyright (c) 2000 David Boyce. All rights reserved. This Perl program is free software; you may redistribute and/or modify it under the same terms as Perl itself.
SEE ALSO
perl(1), "perldoc Env::Path"