If you run this from the command line, will it print out what line and what sub are causing this?

It appears that the crux of the problem lies in Net::SMTP, unless of course more information becomes available, so you could always try grabbing libnet from ppm again. But, I've also got this nagging sensation in my littlest toe that you should check $config{server} and give us more surrounding details to the problem (i.e. +/- 5 lines of code that would give an idea of what may be causing the problem instead of trying to debug from a solitary line).

ALL HAIL BRAK!!!

OK, here's what I did... I removed as many variables as possible, and cut out as much code as I could... and I ended up with a pretty small chunk. This is the whole temp3.pl file:

use Net::SMTP;
my $smtp = Net::SMTP->new('relay.utah-inter.net');
[download]

With ONLY these lines, if I run the script I get:

Bad command or file name
[download]

...so I guess it's just a Net::SMTP thing, at least in Windows 9x with Perl 5.6. It doesn't come through as a Perl error, it's just the Command.com unrecognized command response, so it must be a bad System() call in Net::SMTP. Anybody know an easy trick to absorb this output, so it's not displayed? Maybe redirect STDOUT temporarily in my script? I hate to switch to another module for the problem, the script is working great... it's just this litle nuisance.

Thanks,

Alan "Hot Pastrami" Bellows

Like what I've been mentioning in the CB, run the following at your command prompt:

perl -d temp3.pl

Then step into the Net::SMTP->new call. Now go through each command in the new sub until the

Bad command or file name

is printed. Restart the script and when you get to the line that created the error, step into it (assuming it's a sub). Repeat the method of going to the next command until the error message is printed again. Then, repeat the process. Yeah, it's a drawn out method of finding the problem, but it beats stepping through each sub until you find it. Maybe there's a better way, but I am not the one who knows. :)

Update: This is mostly in reference to finding the problem command and does not actually remove the error message. I'd be appreciative to know if there is a better way to actually get to the command that causes the error without going through the hassle I've come up with as a basic solution.

ALL HAIL BRAK!!!

Hot Pastrami:

The easiest way to hide this error may be to use a variation of the redirect example from open. This works on UNIX:

open(OLDERR, ">&STDERR");
open(STDERR, "/dev/null");
                                 
eval { my $smtp = Net::SMTP->new('relay.utah-inter.net') };

open(STDERR, ">&OLDERR");

die $@ if $@;
[download]

But I don't know what the equivalent to /dev/null is on Windows. Note that just closing STDERR doesn't work, because warn() and die() won't produce output even after STDERR is reopened to OLDERR. I'm not sure why that is.

The eval/die is because, while you want to avoid that warning, if Net::SMTP->new() dies for some reason you want to know about it.

Are you able to execute an even simpler script:

print "Hello, world!\n";
[download]

Does ActivePerl expect a "shebang" line at the top of this Perl script (#!c:\perl\perl.exe or whatever)? It sounds almost like Windows doesn't know how to execute the script. Net::SMTP has no open, system or exec calls in it, so it's odd that it would be generating any error at all like this.

Hey chipmunk...

That's what's really interesting, though... the message isn't in STDERR, it's in STDOUT. I assume a similar means will work with STDOUT if I can determine what /dev/null is on a Win 9x box, right?

Alan "Hot Pastrami" Bellows