Hi HP3000-L,

After I upgraded some CSY lab machines to Perl/iX 5.6.0, some third-party CGI
scripts (that we'll be using for an HPWorld demo) broke.  The web server would
return a "500 server error" message to the browser, and the error_log would
contain (paraphrased):

Can't find <name of third-party perl module> in <list of @INC include
directories>

The module being "require"-ed was spelled correctly, and did indeed exist in
the expected @INC include directory.  The "require" statement itself was
executing without error, but an assignment statement later on creating a new
instance of the object defined by the module was failing and causing the
error_log message.

Investigation revealed three things I want to share with other Perl/iX users:

1) The third-party module was called "Digest", a common name but a really poor
choice because...

2) ...Perl/iX 5.6.0 now comes bundled with an add-on non-core Digest module
whereas the older versions of Perl/iX didn't, and "require" was finding this
bundled Digest instead of the third-party Digest because...

3) ...the third-party script pushed their own module directory name onto the
END of the @INC list after all of the standard Perl include directories, one of
which contains the Digest newly bundled with 5.6.0, and was searched first by
the "require" statement, thus never seeing the intended third-party Digest.

So the moral of the story is try to choose unique module names that are more
than just common words, and when you want to make sure you include your own
modules first before searching for any bundled Perl/iX modules, make sure you
add your own module directories to the FRONT of the @INC list.

- Mark B.