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

Re: Am I running mod perl 2?

Expand Messages
  • Dominique Quatravaux
    ... Hash: SHA1 ... Sorry to be rude about this, but no. This *needs* fixing. http://marc.theaimsgroup.com/?l=apache-modperl&m=112005579327997&w=2 - --
    Message 1 of 9 , Aug 1, 2005
    • 0 Attachment
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

      Geoffrey Young wrote:

      > if $ENV{MOD_PERL} is true you're running under mod_perl.

      Sorry to be rude about this, but no. This *needs* fixing.

      http://marc.theaimsgroup.com/?l=apache-modperl&m=112005579327997&w=2

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

      iD8DBQFC7cuPMJAKAU3mjcsRAqepAJ9CJtTg08g08ApGf1mzFjNadnNZMgCgtZPs
      zX5nPNJ4Osh3ruy4BptydsY=
      =Nf7n
      -----END PGP SIGNATURE-----
    • Philip M. Gollucci
      ... Okay So I read this thread. Whats wrong with: (from your own post) ... Why is that not trustworth ? Are you saying you want a onliner function to return
      Message 2 of 9 , Aug 1, 2005
      • 0 Attachment
        Dominique Quatravaux wrote:
        > -----BEGIN PGP SIGNED MESSAGE-----
        > Hash: SHA1
        >
        > Geoffrey Young wrote:
        >
        >
        >>if $ENV{MOD_PERL} is true you're running under mod_perl.
        >
        >
        > Sorry to be rude about this, but no. This *needs* fixing.
        >
        > http://marc.theaimsgroup.com/?l=apache-modperl&m=112005579327997&w=2
        Okay So I read this thread.

        Whats wrong with: (from your own post)
        >$mod_perl2::VERSION skips these drawbacks (it can only be altered from
        >Perl and is not inherited) but it is currently not trustworthy either:

        >$ perl -Mmod_perl2 -e 'print $mod_perl2::VERSION'
        >2.000001

        Why is that not trustworth ?

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

        1.x
        <1.99022
        >=1.99023 (RC5)
      • 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 3 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 4 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 5 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 6 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 7 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.