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
