Re: IPC::Open2 v5.6.0 failures.
On Sat, Jun 17, 2000 at 09:16:25AM -0400, Barrie Slaymaker wrote: > [EMAIL PROTECTED] wrote: > > > > Is this a know bug? Is there a bug? > > Not that I know of, did you check the archives? Yes but I didn't find the answer I was looking for. I also checked out the guide's Forking and Executing Subprocesses and ... Apache::SubProccess. Apache::SubProccess just hung for me, if I have more time I'll check it out more. > > > Is it right in front of my face? > > Something seems odd to me, see below, but it shouldn't be causing you > too much grief. > > First, to educate me, what's encrypt do differently than Perl's crypt? > why not > >crypt $pass, salt() ; encrypt allows me to use the Blowfish version of crypt; 128 bits vs 12 bits. > > ? > > > If you want to play with it, IPC::Run's up on CPAN and this might make > your routine simpler and more debuggable. You'd do something like this to > use it (untested): > > use IPC::Run qw( run ) ; > > sub encrypt { > my $pass = shift; > my $crypt; > > run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt >or die "Can't run '/usr/bin/encrypt': $!" ; > chomp $crypt; > return $crypt ; > } > > The semantic of &run's return value are what you, or at least I, would > expect. Then, to get a clue about what's happening under the hood, just > add a {debug=>1} to &run's params: > > run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt, {debug=>1} >or die "Can't run '/usr/bin/encrypt': $!" ; > > and see what happens. Increase the debug level to 2 or 3 if need be, > and it probably will be. > > This is a beta module though, so there might be gotchas. One is that I'm > soon going to remove '{'...'}' hash constructors around the debug=>2. > Thanks, I'll check it out. > > Here's what seems odd: > > > open2(\*ENCRD, \*ENCWR, "/usr/bin/encrypt $args") > > or die("Can't open2: '/usr/bin/encrypt': $!"); > > >From the IPC::Open2 man page: > > SYNOPSIS >use IPC::Open2; > >$pid = open2(\*RDRFH, \*WTRFH, 'some cmd and args'); > # or without using the shell > > > >open2() returns the process ID of the child process. It >doesn't return on failure: it just raises an exception >matching `/^open2:/'. However, `exec' failures in the >child are not detected. You'll have to trap SIGPIPE your- >self. > > I don't see how this could this be contributing to your grief, though. > I take it there's no spoor in the error_log? regrardless, open2 will warn on failure. Checking 'wait' and '$?' will tell me if the command failed. But something screwy is going on inside of mod_perl. I'd feel better if I knew what mod__perl was doing with the handles and why the info was being dropped on the way back. I also tried Symbol::gensym, Apache::gensym, and autoviv ... ... no diff. > > As a performance note, have you considered passing the command line as > a list like > > qw(/usr/bin/encrypt -b ), &salt ) > > in place of the string? That way the &exec in &open2 is not invoking > a subshell. Also, if $pass comes from a user, what if they type in > `mail [EMAIL PROTECTED] /etc/passwd`? the $pass is checked long before it makes it to the shell. Well time is too valuable, so my solution for right now is to have a local socket daemon run the encrypt command for me. Just have to remember to have the daemon running ... Thanks for your reply and help. --Wendell
Re: IPC::Open2 v5.6.0 failures.
[EMAIL PROTECTED] wrote: > > Is this a know bug? Is there a bug? Not that I know of, did you check the archives? > Is it right in front of my face? Something seems odd to me, see below, but it shouldn't be causing you too much grief. First, to educate me, what's encrypt do differently than Perl's crypt? why not crypt $pass, salt() ; ? If you want to play with it, IPC::Run's up on CPAN and this might make your routine simpler and more debuggable. You'd do something like this to use it (untested): use IPC::Run qw( run ) ; sub encrypt { my $pass = shift; my $crypt; run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt or die "Can't run '/usr/bin/encrypt': $!" ; chomp $crypt; return $crypt ; } The semantic of &run's return value are what you, or at least I, would expect. Then, to get a clue about what's happening under the hood, just add a {debug=>1} to &run's params: run [qw(/usr/bin/encrypt', -b), salt()], \$pass, \$crypt, {debug=>1} or die "Can't run '/usr/bin/encrypt': $!" ; and see what happens. Increase the debug level to 2 or 3 if need be, and it probably will be. This is a beta module though, so there might be gotchas. One is that I'm soon going to remove '{'...'}' hash constructors around the debug=>2. Here's what seems odd: > open2(\*ENCRD, \*ENCWR, "/usr/bin/encrypt $args") > or die("Can't open2: '/usr/bin/encrypt': $!"); >From the IPC::Open2 man page: SYNOPSIS use IPC::Open2; $pid = open2(\*RDRFH, \*WTRFH, 'some cmd and args'); # or without using the shell open2() returns the process ID of the child process. It doesn't return on failure: it just raises an exception matching `/^open2:/'. However, `exec' failures in the child are not detected. You'll have to trap SIGPIPE your- self. I don't see how this could this be contributing to your grief, though. I take it there's no spoor in the error_log? As a performance note, have you considered passing the command line as a list like qw(/usr/bin/encrypt -b ), &salt ) in place of the string? That way the &exec in &open2 is not invoking a subshell. Also, if $pass comes from a user, what if they type in `mail [EMAIL PROTECTED] /etc/passwd`? - Barrie
Re: IPC::Open2 v5.6.0 failures.
On Fri, 16 Jun 2000 [EMAIL PROTECTED] wrote: > Hi, > > my open2 script failes to work under mod_perl with perl v5.6.0. Works correctly > outside of the 5.6.0-mod_perl environment but works with mod_perl-5.005_03. ... I have the exact same problem using IPC::Open3 under perl 5.6.0/mod_perl 1.24 Its as if everything you write to the filehandle mysteriously disappears before getting to the opened process. I am not sure why this happens. Mike
IPC::Open2 v5.6.0 failures.
Hi, my open2 script failes to work under mod_perl with perl v5.6.0. Works correctly outside of the 5.6.0-mod_perl environment but works with mod_perl-5.005_03. The code comes from '/usr/sbin/adduser'. There are no errors, only the 'RD' handle returns "". As I said works everywhere else but mod_perl-1.24 with perl v5.6.0. This is perl, v5.6.0 built for i386-openbsd Server: Apache/1.3.12 (Unix) mod_perl/1.24 OpenBSD entropic 2.7 entropic#0 i386 Is this a know bug? Is there a bug? Is it right in front of my face? Workarounds? thanks, Wendell *** script is as follows. and a full perl -V follows further ... use IPC::Open2; use strict; print encrypt("thisisapassword"); sub encrypt { my $pass = shift; my $salt = &salt; my $args = "-b $salt"; my $crypt; open2(\*ENCRD, \*ENCWR, "/usr/bin/encrypt $args") or die("Can't open2: '/usr/bin/encrypt': $!"); print ENCWR "$pass\n"; close ENCWR; $crypt = ; close ENCRD; chomp $crypt; die "encrypt failed" if (wait == -1 || $? != 0); return($crypt); } sub salt { 7 } __END__ # perl -V Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=openbsd, osvers=2.7, archname=i386-openbsd uname='openbsd' config_args='-Dopenbsd_distribution=defined -dsE' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='cc', optimize='-O2', gccversion=2.95.2 19991024 (release) cppflags='-fno-strict-aliasing -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=true intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags ='' libpth=/usr/lib libs=-lm -lc libc=/usr/lib/libc.so.25.0, so=so, useshrplib=true, libperl=libperl.so.6.0 Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=define, ccdlflags=' ' cccdlflags='-DPIC -fPIC ', lddlflags='-Bshareable ' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under openbsd Compiled at Jun 4 2000 15:10:45 @INC: /usr/libdata/perl5/i386-openbsd/5.6.0 /usr/local/libdata/perl5/i386-openbsd/5.6.0 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/lib/perl5/site_perl .