[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() ;

?

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

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?

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

Reply via email to