Copyright © 1996-2013,2014 by Thomas E. Dickey

CONFLICT – List filename-conflicts


conflict displays conflicting filenames in your execution path. Unlike the csh command which, it displays all of the conflicting (non-alias) executable filenames in your path.


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:

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.

    -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. As shell functions are slow, they are necessarily less ambitious. Here is a link to a typical example of that, called “checkpath”.

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:

Path directories, in search order

1: /usr/local/bin
2: /users/tom/bin
3: /users/tom/com
4: /usr/sbin
5: /sbin
6: /usr/bin
7: /bin
8: /usr/games
9: .
10: /usr/lib/vile

RCS not found in $PATH
install-info has 2 conflicts
0: -rwxr-xr-x 1 root root 5896 Apr 30 09:24 /usr/sbin/install-info
1: -rwxr-xr-x 1 root root 1216 Oct 14  2010 /usr/bin/install-info

   /usr/sbin/install-info: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
   /usr/bin/install-info: POSIX shell script text executable

linklint has 2 conflicts
0: -r-xr-xr-x 1 tom users 131417 Jan  6 04:18 /users/tom/bin/linklint
1: -rwxr-xr-x 1 root root 131327 Jan 23  2008 /usr/bin/linklint

   /users/tom/bin/linklint: a /usr/bin/perl -- # -*- perl -*- script text executable
   /usr/bin/linklint: a /usr/bin/perl -- # -*- perl -*- script text executable

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.

Current working directory is "/users/ftp/pub/dickey/conflict"
-> /usr/local/bin
--> /users/tom/bin
---> /users/tom/com
----> /usr/sbin
-----> /sbin
------> /usr/bin
-------> /bin
*----*-: bye
---*-*-: dpkg-divert
---*-*-: dpkg-statoverride
-----**: dumpkeys
---*-+-: install-info
---*-*-: install-menu
----*-*: ip
-----**: ksh
-----**: less
-----**: lessecho
-----**: lessfile
-----**: lesskey
-----**: lesspipe
-*---+-: linklint

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.


See the changelog for details: