No, I'd have to edit the module source code because the proper settings for $ENV{PATH} and $ENV{SHELL} are set in one place, my web server, and I have no desire to have 20 CGI scripts with separate, probably out-of-date copies of that configuration information.

If I'm writing a set-UID script, then tainting is correct to tell me that I shouldn't trust PATH nor SHELL (because the user can override these). If you have horrid web server management such that you can't trust these values, then I think your problem is simply "horried web server management". (:

Well, if you want a drop-in replacement, then I'd certainly move away from the @ISA= qw(CGI), change the name, and have users simply add one line to their scripts rather than changing two lines of their scripts.

Please don't use the name "CGI::Safe" unless you address the number one safety problem of CGI: blindly trusting data that comes in over the internet. That is, the "untainting" of CGI parameters. Now, doing that would also justify the @ISA= qw(CGI) design.

The old-style param() method usage could untaint the default way that I described but either a new method or new arguments to param() would allow the coder to specify a regex or subroutine that untaints the data and the module would provide useful templates for common parameter types (like relative paths that don't allow "..").

Actually, I prefer the second option (extending your module). I think it would be great if using CGI::Safe prevented you from ever getting a parameter that didn't match /^\w[-\w.]*\z/ unless you gave it a different specification for that parameter. That would probably do a world of good toward improving CGI code. It would also make using -T easier and would mean that not using -T is no longer a major security error. :)

        - tye (but my friends call me "Tye")