in reply to Developing CGI::Application based modules outside of the default @INC

As an aside, when you are eveloping a CGI application you really don't want to rely upon “the default @INC,” because if someone were somehow able to alter the (external...) value, they would fundamentally alter the behavior of the program.

Therefore, it is wisest to specify an explicit use lib statement.

You may find the FindBin package useful... it has been extensively discussed here in the past, with all its pluses and minuses. You should also review “taint mode.” (I'm making these suggestions partly for the benefit of “the peanut gallery,” not to imply that you're not familiar with these things already.)

Replies are listed 'Best First'.
Re^2: Developing CGI::Application based modules outside of the default @INC
by DBX (Pilgrim) on Apr 10, 2008 at 18:56 UTC
    Actually if you are on a linux/unix platform, I would strongly recommend getting your @INC path from $ENV{PERL5LIB}. This way you never have to change your code and you can change libraries from development or testing or production or anywhere else simply by changing the environment variable. This works equally well for CGI based applications as it does for CLI.
      This works equally well for CGI based applications as it does for CLI.

      Not quite true. Public CGI should use taint mode (as does the code in the original post), which means the environment is untrusted and PERL5LIB has no effect. Environment variables not set by CGI input should be trustworthy though.

      Taint::Runtime can get around this, as can something like this at the start of your script:

      BEGIN { if ($ENV{PERL5LIB} && $ENV{PERL5LIB} =~ /^(.*)$/) { eval "use lib (".join(',', map "'$_'", split ':', $1).");"; die $@ if $@; } }
      (updated to fix a typo)
Re^2: Developing CGI::Application based modules outside of the default @INC
by DBAugie (Beadle) on Apr 10, 2008 at 20:46 UTC
    This member of the peanut gallery appreciates your thoughtfulness. ++