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.
?
PLUG MODULE="IPC::Run" AUTHOR="me" MODE="shameless"
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.
/PLUG
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
snip
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
