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

Re: Am I running mod perl 2?

Expand Messages
  • Dominique Quatravaux
    ... Hash: SHA1 ... Thanks! ... Because we are obviously not *running* under mod_perl, but rather, from a command-line Perl interpreter. The $mod_perl2::VERSION
    Message 1 of 9 , Aug 1, 2005
    • 0 Attachment
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

      Philip M. Gollucci wrote:

      > Okay So I read this thread.

      Thanks!

      >> $ perl -Mmod_perl2 -e 'print $mod_perl2::VERSION' 2.000001
      >
      > Why is that not trustworth ?

      Because we are obviously not *running* under mod_perl, but rather,
      from a command-line Perl interpreter. The $mod_perl2::VERSION method
      might be considered trustworthy enough for checking which version
      (assuming singular!) of mod_perl is *installed*, but nobody cares
      about that. One typically wants to know what version is *running* in
      the current interpreter, in order to adjust behavior accordingly.

      Case in point: when using Apache::DB from mod_perl 1.3 with mod_perl
      2.0 also installed on the same system, the following code (actual
      excerpt from Apache/DB.pm) obviously goes SNAFU.

      use constant MP2 => eval { require mod_perl2; $mod_perl::VERSION >
      1.99 };

      Things get worse if I e.g. want to make some code interoperable
      between standalone CGI and ModPerl::Registry (most likely the intent
      of the original poster in the current thread). Then my admittedly
      bizarre situation of having two mod_perls installed becomes irrelevant
      to the issue at hand. Even with a single, up-to-date mod_perl 2
      installed, any test based upon $mod_perl::VERSION would fail at
      discriminating between /usr/bin/perl and
      /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).

      > Are you saying you want a onliner function to return the version
      > string absolutely regardless of which mod_perl or mod_perls are
      > installed.

      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.

      - --
      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

      iD8DBQFC7k4eMJAKAU3mjcsRAik+AKCBp5LeeZlW97NL/a1g2/y9jeK4VACgn97F
      /Om91wZ9u06SS2k/dk3M7DM=
      =a8FK
      -----END PGP SIGNATURE-----
    • 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 2 of 9 , Aug 1, 2005
      • 0 Attachment
        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 3 of 9 , Aug 1, 2005
        • 0 Attachment
          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 4 of 9 , Aug 1, 2005
          • 0 Attachment
            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 5 of 9 , Aug 1, 2005
            • 0 Attachment
              -----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.