Loading ...
Sorry, an error occurred while loading the content.
 

Re: Am I running mod perl 2?

Expand Messages
  • Philip M. Gollucci
    ... Okay, I at least understand what you are saying now. I think what you re getting at is that (other then ENV tampering) is that the websver once it sees and
    Message 1 of 9 , Aug 1, 2005
      Dominique Quatravaux wrote:
      > /usr/lib/apache2/modules/mod_perl.so. And $ENV{MOD_PERL} does not cut
      > it either, for other reasons detailed in my previous post (wrong scoping).
      Okay, I at least understand what you are saying now.

      I think what you're getting at is that (other then ENV tampering) is
      that the websver once it sees and successfully loads

      LoadModule perl_module modules/mod_perl.so

      $ENV{MOD_PERL}

      will be in your environment even if you happen to be running a REGULAR
      CGI from /cgi-bin on mod_cgi.

      Correct me if I'm wrong while I think about this more.
    • Joe Schaefer
      ... I like the second-best option, actually: IMO require mod_perl2 should throw an exception unless we re actually running under the mod_perl.so interpreter.
      Message 2 of 9 , Aug 1, 2005
        Dominique Quatravaux <dom@...> writes:

        > I would like a robust way of checking the mod_perl version (or lack
        > thereof) of the *currently running* Perl interpreter. I did kludge up
        > one, but it is rear-end ugly (see code at the end of my post in the
        > other thread).
        >
        > Support from mod_perl itself (e.g. in the form of a running_version()
        > XS sub) would be helpful and robust. Causing mod_perl2.pm to fail
        > initialization when not running under mod_perl (using an XS detection
        > kludge like mine, *not* $ENV{MOD_PERL}) would be a second best.

        I like the second-best option, actually: IMO "require mod_perl2"
        should throw an exception unless we're actually running under the
        mod_perl.so interpreter. People that only care about the installed
        version would just need to

        eval {require mod_perl2};
        if ($@) {
        if ($@ =~ /^Can't locate mod_perl2/)
        $have_modperl2 = 0;
        elsif ($@ =~ /^Not running under mod_perl.so/)
        $have_modperl2 = 1;
        }
        else {
        # running under mod_perl.so
        $have_modperl2 = 1;
        }

        --
        Joe Schaefer
      • Joe Schaefer
        ... I should have pointed out tho that a change like this certainly shouldn t happen in mp2.0. For better or worse, we chose to use $ENV{MOD_PERL} to signal
        Message 3 of 9 , Aug 1, 2005
          Joe Schaefer <joe+gmane@...> writes:

          > Dominique Quatravaux <dom@...> writes:
          >
          >> I would like a robust way of checking the mod_perl version (or lack
          >> thereof) of the *currently running* Perl interpreter. I did kludge up
          >> one, but it is rear-end ugly (see code at the end of my post in the
          >> other thread).
          >>
          >> Support from mod_perl itself (e.g. in the form of a running_version()
          >> XS sub) would be helpful and robust. Causing mod_perl2.pm to fail
          >> initialization when not running under mod_perl (using an XS detection
          >> kludge like mine, *not* $ENV{MOD_PERL}) would be a second best.
          >
          > I like the second-best option, actually: IMO "require mod_perl2"
          > should throw an exception unless we're actually running under the
          > mod_perl.so interpreter.

          I should have pointed out tho that a change like this certainly
          shouldn't happen in mp2.0. For better or worse, we chose to use
          $ENV{MOD_PERL} to signal the runtime.

          --
          Joe Schaefer
        • Dominique Quatravaux
          ... Hash: SHA1 ... Part of the problem indeed. There are other practical problems (e.g. PerlSetupEnv Off used to disable $ENV{MOD_PERL} under mod_perl 1.3,
          Message 4 of 9 , Aug 1, 2005
            -----BEGIN PGP SIGNED MESSAGE-----
            Hash: SHA1

            Philip M. Gollucci wrote:

            > Okay, I at least understand what you are saying now.
            >
            > $ENV{MOD_PERL}
            >
            > will be in your environment even if you happen to be running a
            > REGULAR CGI from /cgi-bin on mod_cgi.

            Part of the problem indeed. There are other practical problems (e.g.
            PerlSetupEnv Off used to disable $ENV{MOD_PERL} under mod_perl 1.3,
            don't know if this is still the case). Also we may be invoking Perl
            scripts from mod_perl using a piped open(), although we arguably could
            mangle the %ENV by ourselves then.

            Also the code purity department inside me thinks it's obvious that a
            Perl notion (mod_perl version) should be materialized through a Perl
            mechanism (variable or sub) instead of the UNIX env, but maybe that's
            just me. No software library that I know of signals its version number
            by setting an environment variable at program startup! Therefore the
            whole $ENV{MOD_PERL} idea very much looks like a bad NCSA-legacy
            thinko to me (mimicked from $ENV{GATEWAY_INTERFACE}, which *does*
            actually make sense).

            - --
            Dominique QUATRAVAUX Ingénieur senior
            01 44 42 00 08 IDEALX

            -----BEGIN PGP SIGNATURE-----
            Version: GnuPG v1.2.5 (GNU/Linux)
            Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

            iD8DBQFC7mZgMJAKAU3mjcsRAkhdAKCxT1MDpLTeRckPN67npCCmS2Oa8gCdE5dl
            N7MRmpOdCMzfzWEbCqULZJI=
            =lIm8
            -----END PGP SIGNATURE-----
          Your message has been successfully submitted and would be delivered to recipients shortly.