Ubuntu Manpage: envpath - Advanced operations on path variables

Provided by: libenv-path-perl_0.19-2_all

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 expanded with @NAME@. For example

envpath PATH=@PATH@,/usr/ucb -- printenv PATH

appends "/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
envpath PATH+=/usr/ucb -- printenv PATH

# place /usr/ucb at the back
envpath PATH=+/usr/ucb -- printenv PATH

Simple 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.

envpath -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.

The -Whence option allows patterns. Thus

envpath -W "cat*"

would find all programs on PATH which match cat*.

CLEARCASE WINKINS

A big part of the motivation for this script was for use with ClearCase builds; iff 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 or runtime errors, however, and makes
it hard for new users to get up to speed since their personal environment must be just so.

Another common choice is to use only full pathnames within the Makefile, avoiding reliance on search
paths at all. This is often the best way to go but can suppress 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 pre-built utility that's in different places on different
platforms; "yacc", for instance, is in /usr/bin on Linux and /usr/ccs/bin on Solaris.

You could modify the path on the fly:

$(INCDIR)/foo.h: $(BINDIR)/foomaker PATH=$(BINDIR)$(SEP)$$PATH foomaker ...

but this suffers from the same problem: since $(BINDIR) and $PATH are expanded literally within the build
script they'll suppress winkins. Here's a solution using envpath:

$(INCDIR)/foo.h: $(BINDIR)/foomaker envpath PATH=@BINDIR@,@PATH@ foomaker ...

This hides 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 it's the
original reason it was written.

AUTHOR

       David Boyce <dsbperl AT boyski.com>

COPYRIGHT