That's why I was asking if this was in support of legacy code. Most cases where this used to be needed would be handled with lexicals these days, so they are mostly reserved for things like $/. There are other ways to do what the OP is after, and I think they would probably be less confusing to non-expert Perl coders.

I'm not sure what you see as strange: the use of globals in general, or the use of local ?

Regardless:

Q1. Why am I using globals at all; aren't globals evil ?

A1. The code in question is part of some authentication/access control logic which runs structurally identical code in both CGI and mod_perl environments. This means that there's only one code base to make fixes in, add features to, review for security issues, etc. (And that's a GoodThing(tm)).

To simplify the task of writing the code in a mod_perl/CGI independent fashion, I make certain data available via a small number of globals. (There may be a cleaner solution, but I couldn't see one at the time I was writing it).

So globals may be evil, but in this case, they simplified things sufficiently that I'm happy to live with the shame and debasement of my soul.

Q2. Why are globals localized ?

A2. Because globals are potentially evil, in that if one isn't too careful, in the wrong environment, (mod_perl perhaps) their contents may persist for longer than one would wish (and perhaps expose usernames, cookies, etc to another handler). So to mitigate this problem, they've been localized to the dynamic scope of the handler routine, and thus we can (I hope) rely on Perl to undef them at the end of the handler (but leaving them usefully available while the handler is executing)

Does that help ?

Steve Collyer

That does make more sense. I generally put that stuff in %ENV, so that both of them can read it. The environment variables don't persist between requests in mod_perl. Alternatively, I sometimes make a simple fetch/store API which uses $r->pnotes() under mod_perl and globals under CGI. (Hmm, possible CPAN module?)