lesenfantsterribles.pm seems to be one of your own modules, but all of the directories you have in @INC are on system level. In which directory is that module to be found?

A frequent reason why software with homegrown modules suddenly stopped working is that as of Perl 5.26, "." [is] no longer in @INC. So, if your programs rely on finding that module in the "current directory", this won't work with newer Perls.

If adding a use lib with the correct absolute path to the directory doesn't help: Does Freehostia run their web stuff (which I guess is what you have) in a chroot environment? In that case you need to add the directory as the web server sees it.

Thanks. The listed version of Perl is 5.24.1 and they insist they haven't changed anything. When I add a use lib it lists it correctly in the error listing (showing the contents of @INC) I have tried both relative and absolute paths and it makes no difference. Excuse my ignorance but how can I discover "as the web server sees it."?

Thanks. The listed version of Perl is 5.24.1

So that's an inconsistency. In Perl 5.24.1, '.' is in @INC, but your output does not show it. So someone has done something to remove it (and in fact, removing it manually was recommended in perl5421delta).

...and they insist they haven't changed anything.

For obvious reasons, I can not verify that claim. That's between you and them.

Excuse my ignorance but how can I discover "as the web server sees it."?

Since you haven't provided much details about your environment, I can only guess that this is some web hosting, and you can write CGI programs in Perl. If that's the case, write a CGI program which examines the directories in question and prints the file names, ownership and permissions, and also the user and group id under which the program is running.

Things to check:

1. There's definitely a file called $dir/lesenfantsterribles.pm for some $dir that's in your @INC. Can you confirm this?

2. The case matches your use statement. use Foo will load Foo.pm but use fOO will load fOO.pm... unless you're on a case-insensitive filesystem, which you are probably not.

3. Let's say the module is /usr/share/perl5/lesenfantsterribles.pm. Then check /usr/share/perl5/lesenfantsterribles.pm is readable by whatever user the web server is running under. Also check /usr/share/perl5/, /usr/share/, /usr/, and / are readable and executable by that same user. Even if the permissions look right, check they can actually be read. Try using cat or less to view the file contents.

Thank you. I can definitely confirm querstions 1 and 2. This error has occurred on all 8 sites running on that host - not just one and the modules all have lower case names to avoid spelling mistakes - and some have been running over 10 years. I don't see how they can't be useable/readable as both the directories and the modules have 0755. I know almopst nothing of unix and as far as I know there is no "command line" anywhere. I think I'll write a snippet to read the module as a file to check

Just a wild guess -- the '.' directory used to be included in @INC automatically in earlier versions of Perl, but this host might have recently updated to a newer Perl. Is lesenfantsterribles.pm in your local directory? You may need to add use lib '.'; to your code.

I think that's the browser writing the error page that is doing that as the paths do not have any spaces in the,