Re: how to run regex calculation
On Thu, Jan 09, 2020 at 10:36:19AM +0800, Wesley Peng wrote:
> $str = "2 3 6";
>
> I want to match with:
>
> true if $str =~ /(\d+)\s(\d+)\s($1*$2)/;
>
> that's to say, the thrid column would be (firstCol * SecondCol).
>
> How to write regex for this?
I don't think you can do it directly in the regex. You'll need to do the
math separately:
if ($str =~ /^(\d+)\s(\d+)\s(\d+)$/ && $3 == $1 * $2) {
print "true\n"
}
else {
print "false\n";
}
Re: [a bit OT] AuthCookieDBI and Apache 2.4
On 2/21/2019 9:46 AM, Michael Schout wrote: Another common thing I've seen people do is return an invalid Apache2::Const value from an Authz provider. You must return one of a Yup, been there done that :). I pieced this together, if my memory is correct, from apache mailing list posts, as well as reading the source code of apache itself. I'm not sure I found any definitive guide on the changes when I did this, and it involved a good deal of research at the time. Thanks much for putting that together, I found it an invaluable (and unique) resource in figuring out how that black box worked 8-/.
Re: AuthCookieDBI and Apache 2.4
On Wed, Feb 20, 2019 at 05:56:48PM -0500, Edward J. Sabol wrote: > Any pointers to a working AuthzProvider written in Perl (like for the > "species" one) in your examples? It's not perfectly clear to me how to > go about that. I wrote one for CAS auth a while back: https://github.com/pbhenson/Apache2-AuthCASpbh/blob/master/lib/Apache2/AuthCASpbh/Authz.pm
Re: Apache upgrade 2.2 -> 2.4 and "PerlAuthenHandler Authen::Simple::IMAP"
On 2/19/2019 6:02 PM, Jie Gao wrote: Found this on CPAN: Module < Authen::Simple::IMAP (DMARTIN/Authen-Simple-IMAP-0.1.2.tar.gz) Hmm, perhaps I should have searched CPAN directly rather than relying on Google :). Thanks for the pointer… The last update for this module was in 2009; Apache 2.4 was released in 2012, so without even looking at the code I am fairly confident the module does not support it. The documentation comment "I've never tried this in mod_perl, so including the mod_perl example in the synopsis is pure hubris on my part" is also perhaps illuminating :). Hmm, actually, it looks like the module in need of update is Authen::Simple::Apache, not Authen::Simple::IMAP itself. That one was last released in April 2012, but does not appear to include Apache 2.4 support. You could try contacting the author of that module to ask if he would be willing to update it? Or if you are handy at coding, you could try to update it yourself, or contract somebody do it for you. There are a few other authentication modules out there with 2.4 support that could serve as examples, including https://metacpan.org/pod/Apache2::AuthCASpbh :).
Re: Apache upgrade 2.2 -> 2.4 and "PerlAuthenHandler Authen::Simple::IMAP"
On 2/19/2019 5:33 PM, Jobst Schmalenbach wrote: While I have fixed most of the issues realted to the upgrade of Apache one I cannot solve is the "PerlAuthenHandler Authen::Simple::IMAP" in .htaccess files. The authentication/authorization API changed between 2.2/2.4, if this module has not been updated to accommodate that, there is no way to fix this issue other than updating the module to work with the new API. Where does this module come from? The only thing I can find is: https://metacpan.org/pod/Authen::Simple which does not appear to include an IMAP component.
Re: HTTP and MPM support
On 1/28/2019 1:53 PM, Mark Blackman wrote: https://perldoc.perl.org/threads.html#WARNINGÂ Threads are discouraged in Perl these days Yes, that is indeed what the documentation says; however, there is a far cry between "Perl is single-threaded by design and history and has no reliable support for threading" and "use of threads is discouraged in perl". Looking back to the original discussion that led to that caveat https://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg213382.html a good summary of why it is there is: "The patch came about because unmanaged expectations of support are causing social problems" And further discussion about it https://www.perlmonks.org/?node_id=1107534 has a similar insight: "that this particular formulation is just smoke and mirrors to repel 'annoying newbies" Then in this bug discussing the verbiage https://rt.perl.org/Public/Bug/Display.html?id=133021 a developer comments: "The fact is that threads work, they are maintained, and they currently do not have any bugs preventing their use." Basically, perl threads are heavyweight, not lightweight, and use of non-thread safe Perl code whether your own or in third-party modules will cause potentially nondeterministic problems. The warning is basically there to scare away people who don't have sufficient expertise to make it work and will likely come complain and ask for help with something the developers don't want to have to explain over and over again. Back when I was running DCE/DFS and maintaining the perl modules on top of that, I used threaded perl heavily with no issues. As long as the mechanism of and caveats regarding Perl threads are understood, and there is a justifiable reason to be using them rather than some other construct, discouraged is not deprecated nor unavailable/unreliable.
Re: HTTP and MPM support
On 1/28/2019 12:38 PM, Mark Blackman wrote: > Given that Perl is single-threaded by design and history and has no reliable support for threading, I think that mod_perl and direct http/2 Perhaps I am confused, but I do not necessarily agree with this statement. See, for example: https://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support Both perl and mod_perl support threads, typically the problem arises not with native Perl thread support, but rather thread-unsafe user code or modules.
Re: HTTP and MPM support
On 1/25/2019 11:00 AM, Michael A. Capone wrote: I have to add my voice to the growing chorus here. Me too. Frequently when the topic of mod_perl going stale comes up somebody jumps in with "That's old stuff, you should be using PSGI/Plack". Those people simply don't understand the overall utility of mod_perl beyond simply running a webapp . I have authentication and authorization handlers written in mod_perl, and the ability to directly access the Apache API allows things that PSGI simply cannot do.
Re: Future MPM Support?
On Sun, Jul 29, 2018 at 04:18:54PM -0400, Paul Silevitch wrote: > Like Dr. James Smith, I'm hooking into multiple handlers and using filters. Yep, me too; Plack is really not a feature equivilent replacement for mod_perl :(.
Bug #122988? mod_perl still maintained?
Looks like I'm running into: https://rt.cpan.org/Public/Bug/Display.html?id=122988 which was reported back in 9/2017. There doesn't seem to be a resolution to it? I diff'd 2.0.10 (released in 10/2016) against current svn head, and there really don't seem to be any changes of significance. Is mod_perl still under active development/being maintained? Any thoughts on this problem? Thanks much... -8<-- Start Bug Report 8<-- 1. Problem Description: Trying to use Apache2::Module::add in a module loaded by PerlLoadModule resulted in errors: [Wed Mar 07 13:23:39.827007 2018] [core:notice] [pid 100372] AH00060: seg fault or similar nasty error detected in the parent process [Wed Mar 07 13:25:45.255839 2018] [core:crit] [pid 65829] AH00102: [Wed Mar 07 13:25:45 2018] file config.c, line 576, assertion "total_modules < conf_vector_length" failed 2. Used Components and their Configuration: *** mod_perl version 2.10 *** using /usr/lib64/perl5/vendor_perl/5.24.1/x86_64-linux-thread-multi/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_CONFIG => /usr/bin/apr-1-config MP_APR_LIB => aprext MP_APXS=> /usr/bin/apxs MP_COMPAT_1X => 1 MP_DEBUG => 0 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_NO_THREADS => 0 MP_TRACE => 0 MP_USE_DSO => 1 *** The httpd binary was not found *** (apr|apu)-config linking info -laprutil-1 -lldap -llber -ldb-5.3 -lexpat -L/var/lib/portage/tmp/portage/dev-libs/apr-util-1.5.4/temp -lapr-1 -luuid -lrt -lcrypt -lpthread -ldl *** /usr/bin/perl -V Summary of my perl5 (revision 5 version 24 subversion 3) configuration: Platform: osname=linux, osvers=4.9.44-gentoo, archname=x86_64-linux-thread-multi uname='linux mole 4.9.44-gentoo #3 smp thu aug 24 10:27:24 pdt 2017 x86_64 intel(r) xeon(r) cpu e5-2640 v3 @ 2.60ghz genuineintel gnulinux ' config_args='-des -Dinstallprefix=/usr -Dinstallusrbinperl=n -Ui_ndbm -Ui_gdbm -Di_db -Dusethreads -DDEBUGGING=none -Dinc_version_list=5.24.2/x86_64-linux-thread-multi 5.24.2 5.24.1/x86_64-linux-thread-multi 5.24.1 5.24.0/x86_64-linux-thread-multi 5.24.0 -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Dnoextensions=ODBM_File GDBM_File NDBM_File -Duseshrplib -Darchname=x86_64-linux-thread -Dcc=x86_64-pc-linux-gnu-gcc -Doptimize=-march=x86-64 -msse3 -O2 -pipe -Dldflags=-Wl,-O1 -Wl,--as-needed -Dprefix=/usr -Dsiteprefix=/usr/local -Dvendorprefix=/usr -Dscriptdir=/usr/bin -Dprivlib=/usr/lib64/perl5/5.24.3 -Darchlib=/usr/lib64/perl5/5.24.3/x86_64-linux-thread-multi -Dsitelib=/usr/local/lib64/perl5/5.24.3 -Dsitearch=/usr/local/lib64/perl5/5.24.3/x86_64-linux-thread-multi -Dvendorlib=/usr/lib64/perl5/vendor_perl/5.24.3 -Dvendorarch=/usr/lib64/perl5/vendor_perl/5.24.3/x86_64-linux-thread-multi -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dvendorman1dir=/usr/share/man/man1 -Dvendorman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3pm -Dlibperl=libperl.so.5.24.3 -Dlocincpth=/usr/include -Dglibpth=/lib64 /usr/lib64 -Duselargefiles -Dd_semctl_semun -Dcf_by=Gentoo -Dmyhostname=localhost -Dperladmin=root@localhost -Ud_csh -Dsh=/bin/sh -Dtargetsh=/bin/sh -Uusenm -Ui_ndbm -Ui_gdbm -Di_db -Dusethreads -DDEBUGGING=none -Dinc_version_list=5.24.2/x86_64-linux-thread-multi 5.24.2 5.24.1/x86_64-linux-thread-multi 5.24.1 5.24.0/x86_64-linux-thread-multi 5.24.0 -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Dnoextensions=ODBM_File GDBM_File NDBM_File' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='x86_64-pc-linux-gnu-gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-march=x86-64 -msse3 -O2 -pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe' ccversion='', gccversion='5.4.0', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678, doublekind=3 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='x86_64-pc-linux-gnu-gcc', ldflags ='-Wl,-O1 -Wl,--as-needed' libpth=/usr/local/lib64 /lib64 /usr/lib64 /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/include-fixed /usr/lib /lib/../lib64 /usr/lib/../lib64 /lib libs=-lpthread -lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc libc=libc-2.25.so, so=so, useshrplib=true, libperl=libperl.so.5.24.3 gnulibc_version='2.25' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC',
