in reply to Namespace debugging advice

If require isn't failing on loading the file, then I'd suspect that the sub in question has been removed from the required file, or renamed. Have you checked to see whether someone's played with that file?

The following code snip will print out all subs currently within your namespace. Run it after the require and look for the sub in question, and see if other subs from that file have loaded properly.

use warnings; use strict; require "file"; my @list = keys %main::; for (@list){ my $sub = "main::$_"; print "$_\n" if defined &$sub; }

ps. If you haven't already, I'd *highly* recommend that you get all of your files checked into a version control system, so you can track this kind of thing.

Replies are listed 'Best First'.
Re^2: Namespace debugging advice
by dorianwinterfeld (Acolyte) on Jan 27, 2016 at 21:36 UTC
    Thanks for the suggestions. Yes, I did check that the sub in question exists in the library. And I plan to set up a git repo asap.
      Paste my code above into a separate script file (replacing "file" with your actual include), run it, and see what you get. This will eliminate your other dependencies from pissing over the test. If the sub still doesn't show up, we'll have to see the code in the include file, at minimum. Essentially, you want to "halve" the problem until you figure out what you broke.
        Thanks! You helped me solve it! It was a namespace problem. I ran your test and there are 1353 subs in main. Then I printed the package name at the top of the lib file, db2access.pli. It was not "main", it was "FR_html_tools", which it had inherited from a PM file. I printed out the subs in FR_html_tools and there were all the missing subs, including the one I need, &DB2QUERY. Now I can call the sub with it's namespace; FR_html_tools::DB2QUERY() and the cgi script finds it fine. Thanks again. There are many PM files in this code and it's hard to keep track of all the package names.