Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Can I use this windows sendmail with Mail::Mailer from a location other than "\usr\lib"? I thought maybe I had to set $ENV{'PERL_MAILERS'} but it seems to still not find it? Anybody know what's wrong? Is it my sendmail? Also, is there a sendmail for OSX that I can call when the script is on that platform? Thanks.

Replies are listed 'Best First'.
Re: sendmail on windows- unique location
by antirice (Priest) on Nov 03, 2005 at 04:53 UTC

    Hmmm, I just tried using that sendmail program with Mail::Mailer and finally got it to work. Please note that getting it to work isn't easy and requires you to edit Mail::Mailer's source to get it to work properly on windows. Also, please be certain that your perl is 5.6.1 or later.

    First, here's my test script:

    #!/usr/bin/perl -l BEGIN { $ENV{'PERL_MAILERS'} = 'sendmail:c:\sendmail.exe'; } use Mail::Mailer "sendmail"; my $m = Mail::Mailer->new(); $m->open({qw( From someone@somewhere.com To someone@someotherplace.com Subject hey )} ); print $m "Hi"; $m->close;

    Please make certain you're putting '.exe' at the end of the executable or it'll complain that it can't find the executable. Now we have to work around a problem with Mail::Mailer. Unfortunately, it uses open($self,"|-") which, if you've read perldoc perlfork, isn't implemented on windows yet. However, there's a workaround. You'll need to add the following code to Mail::Mailer's source (preferably towards the end):

    sub pipe_to_fork { my $parent = shift; pipe my $child, $parent or die; my $pid = fork(); die "fork() failed: $!" unless defined $pid; if ($pid) { close $child; } else { close $parent; open(STDIN, "<&=" . fileno($child)) or die; } $pid; }

    You will then need to go to line 269 and change open($self,"|-") to pipe_to_fork($self).

    Once you've done that, it should work. If it doesn't please reply below.

      Thanks! I would not have ever cought the windows Mail::Mailer error.
Re: sendmail on windows- unique location
by Delusional (Beadle) on Nov 03, 2005 at 08:39 UTC
    I've never used the Mail::Mailer, however, in most situations, you can add the path to any executable to the normal system environment veriable %PATH%, and, in this case, Windows will be able to find the executable with the normal system call. Thus changing the Windows veriables to have "c:\usr\lib\" to the %PATH% variable, and placing sendmail.exe in this directory, would, normally, allow Windows to find the executable when issueing sendmail to the system (as most mail sending scripts do).

    To see your current path on Windows, open a command window, and enter echo %PATH%. Any program located in any director listed there, will automatically be executed, if matched (it doesn't matter to Windows if the call is for sendmail and the first found is sendmail.cmd or sendmail.bat or sendmail.exe, it will execute the first found match to sendmail).
      That's good to know. Is there ever conflict with user privilege and changing system environment veriables? I'm not admin on my schools computers/render farm.
        Changing these variables depents on how the system is configured.

        In some cases, setting set path=somedrive\somepath in the autoexec.bat may work, but then again, it may not. Again this depends on how the system is configured (user rights). For informaiton on the autoexec.bat, look on google or in an old DOS manual.

        To use the Windows method, right click on My Computer and choose Properties (if you have the icon on the desktop) or open the Control Panel (change to classic view) and start System. Change to the panel labled Advanced, then click the button labled Environment Variables, edit the Path in the System Variables section to what you want/need it to be, click OK, OK, OK, to get back out. Any programs started (but not spawned) *after* you made this change will get the new information. So to ensure the new variable information is available system wide, restart the system.

        Your Administrator may restrict your access, so none of this may actually work.

        And finally, this may not actually work for the sendmail for Windows discussed here. As Windows may not pass the right informaiton to the program, resulting in the program not finding its files (such as the ini file). Additionally, it may or may not work, depending on how the sendmail is actually called within the actuall script (a system call means Windows handles it, thus the %PATH% variable is present, a spawn call may not be as 'fortunate').