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


       envpath - Advanced operations on path variables


       Run this script with the "-help" option for usage details.


       Parses the command line, modifies the specified path variable(s), and execs the remaining
       arguments. There are two modes, simple and advanced:

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


       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.


       David Boyce <dsbperl AT>


       Copyright (c) 2000-2001 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.


       perl(1), "perldoc Env::Path"