I wrote this in 1988, based on a script that I wrote while at
the ITT Advanced Technology Center to analyze execution-path and
environment conflicts on VM/SP CMS. Since then, I've added the
ability to scan for different types of conflicts (e.g., along an
include-path for C compilers).

I wrote the original script in 1982, in EXEC2, to help
troubleshoot problems that I encountered in sharing my XEDIT
macros with other developers. With CMS, the potential for naming
conflicts was different from Unix-style systems. There were two
dimensions:

CMS had multiple layers of command-interpreters. For
instance, a command issued within XEDIT was first checked in
that editor, then (if not recognized there), forwarded to the
EXEC/EXEC2 level, and finally to the CP level.

CMS also distinguished access privileges to the
“minidisks” which were mounted in a user's
environment by a numeric code.

In short, the script analyzed the user's environment to report
naming conflicts which would interfere with a script's
operation.

Oddly, this tool is not widely used. There are no comparable
programs (so it is not simply a case of faring badly with
competition). Rather, almost all discussion in the technical area
deals with setting one's PATH environment
variable.

I wrote one of those in June 1994, called
newpath. Here is its usage summary, to give a
flavor:

Usage: newpath [options [directories]] [ - command]
Echos the PATH environment variable with the given directories added
(the default) or removed.
Options:
-a NAME modify path after given NAME
-b put new arguments before existing path
-d remove duplicates/non-directory items
-e put new arguments after end of path
-f allow filenames to match, as well as directories
-n NAME specify environment-variable to use (default: PATH)
-p print in C-shell form
-r remove arguments from path
-v verbose
Put a '-' before a command which is invoked with the environment variable
updated, rather than echoing the result to standard output.

That is a compiled executable. But again, most activity in the
area has a different focus, e.g., shell functions (rather than
compiled applications) which do some of the features which my
application does. I wrote newpath initially as a shell
script, and rewrote it as a C program for that reason. The reason
why I wrote newpath was that in the project where I was
working, we used NFS-mounted home directories on a variety of
Unix servers (SunOS 4.1.3, Solaris 2.3, IRIX 5.3 and 6, etc.),
which had different tools available for each environment. My
.cshrc file set a variable to a list of the possible
directories, newpath tested those once and produced a
workable PATH. Here is an example from my current
.cshrc:

As shell functions are slow, they are necessarily less
ambitious than conflict. At the same time as
newpath, I wrote a cut-down variant of
conflict, path as a script:

without parameters, the script prints the names of the
directories in PATH, one per line. It ignores
directories which do not exist.

with parameters, the script (again checking for existence)
passes those to ls, showing the details of
each match.

For a single file of interest, path and
conflict give similar results. I wrote this as a stopgap
while awaiting approval to bring in sources for my tools (mainly
ded).

Later, I considered making a version of newpath for
Windows, but put that idea aside (because the approach would
necessarily have been more cumbersome). Some people (see
this have done useful work in that area.

Still, there are a few scripts which do some part of
the functionality of conflict. Here
is a link to an example (also named “checkpath”)
which prints a report. For example, here is the beginning of its
(rather long and verbose) report on my machine:

That is the default output. There is a terse mode
which prints the names and the number of conflicts. Here is a
comparable section of the report from conflict
which shows where the conflicts come from, and whether they are
due to identical (linked) files or different files. Incidentally
the report citing “RCS” is bogus, since it is a
symbolic link to a directory.

Likewise,
this unnamed Python script uses a verbose approach to the
problem. It is not a general-purpose tool however, since it
requires an XML file as input.

Another example, pathfinder, is a
little less verbose primarily by collapsing the information for
each name onto a single line. Aside from that, it is not an
improvement over the first “checkpath” script:

RCS in /users/tom/com is shadowed by /users/tom/bin
run-linklint in /users/tom/com is shadowed by /users/tom/bin
setup-kde in /users/tom/com is shadowed by /users/tom/bin
umount.hal in /sbin is shadowed by /usr/sbin
bye in /usr/bin is shadowed by /usr/local/bin
copyrite.txt in /usr/bin is shadowed by /users/tom/bin
dpkg-divert in /usr/bin is shadowed by /usr/sbin
dpkg-statoverride in /usr/bin is shadowed by /usr/sbin
install-info in /usr/bin is shadowed by /usr/sbin
install-menu in /usr/bin is shadowed by /usr/sbin
linklint in /usr/bin is shadowed by /users/tom/bin

Besides a less-verbose report, the feature which I use in
conflict is absent from each of these examples:
the ability to construct a list of pathnames for analysis. I pipe
the output of conflict into ded and get the timestamp and size
information in a sortable display, for free.

The Windows and OS/2 port of conflict shows a
different report than the POSIX one. That is because there may be
more than one executable using the same name in a
directory, differing only by type. Here is an
example:

The “B” and
“E” markers on the left denote the file
types which are expanded on the right, The
“.BAT” and
“.EXE” Technically, the permissable
types are enumerated in the environment variable
PATHEXT. However, I have not (yet) modified
conflict to use this information because it
would involve some rethinking of the fairly compact report. It
would be very wide if each type had a column. Use your
imagination:

PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

Again, with Windows, others have had the same problem, with
most of the attention being on making the PATH
readable. Here are a few links to relevant discussion: