Don't particularly wish to locate all the packages and install them.

Arjen

Well I do take your point, thanks for it, and will see what I can do about loading the correct things. However, in fact the program has worked completely properly for more than a year so the error messages are no more than annoying. I believe many of the modules that Mime::Lite uses are optional and I don't use them so I guess that why it works...

According to the CGI::Carp documentation, you can only turn warningsToBrowser on and off (the warnings will be inserted as HTML comments). I'm afraid that the fatalsToBrowser thing is an all or nothing proposition. You can of course still use CGI::Carp without fatalsToBrowser, but then all the messages will get logged only in the logfiles. This may or may not be appropriate for your purposes.

Arjen

The paranoid option isnt relevent to you or your problem, dont use it. (In fact its arguable that it was a mistake to provide it.)

The errors you are getting are very odd. Please check that your MIME::Lite version is up to date, and change the require to a use. Also, I _would_ go through the effort of updating and or installing the various modules involved. BTW: The fact that the 'Net/LocalCfg.pm' occurs is very odd, IndigoPerl is doing something very strange. Update your lib-net and see what happens. Also, while I wont say that this is the cause I will say installing Perl into a directory with spaces in its name is just plain and simply a _bad_ idea.

Thank you - yes I will do what you say and let you know.

OK, I have created a brand new server (WinXP Prof), reinstalled Indigo Perl 5.6 build 09 using a directory path without any spaces and used the Indigo Perl GUI package manager (which now works due to no-space path) to install reqd. modules including MIME::Lite 3.01 from active state.

Yes, this seems to have removed most of the errors. Thanks. I'm sure it was the spaces in the path that was causing the trouble.

However, errors do still happen viz:

The system cannot find the path specified. [Tue Feb 10 11:18:09 2004] 
+op.cgi: Use of uninitialized value in scalar assignment at C:/indigop
+erl/site/lib/Net/Domain.pm line 202. [Tue Feb 10 11:18:09 2004] op.cg
+i: Use of uninitialized value in scalar assignment at C:/indigoperl/s
+ite/lib/Net/Domain.pm line 202. [Tue Feb 10 11:18:09 2004] op.cgi: Us
+e of uninitialized value in pattern match (m//) at C:/indigoperl/site
+/lib/Net/Domain.pm line 226. [Tue Feb 10 11:18:09 2004] op.cgi: Use o
+f uninitialized value in split at C:/indigoperl/site/lib/Net/Domain.p
+m line 233.
[download]

Version of Domain.pm is V2.13.

Any comments?

I've also attempted to 3.01_03 so as to Beta trial it. Regrettably, I don't have nmake on my machine. I've only ever installed the modules using user-friendly utilities that just download and install modules/packages from activestate repository or wherever. I don't know how they work but I assume they install pre-compiled windows binaries somehow. Is there some repository I can go to to get 3.01_03 in this way?

I expect not. I don't entirely understand why PERL lib downloads need to be compiled - I thought that PERL was an interpreted language. I understand that one might wish to compile a script to make it faster but it seems odd that compilation is compulsory. Can't I just include the source into my script somehow? (no doubt, a naive question...). Perhaps some other shaven-heads have some thoughts on this to enlighten my foolish soul.

Secondly, hiding the error won't make it go away. Mime::Lite isn't loading properly. That means that functions from it that you might want to access won't be there. Your software may appear to work in many ways, but I guarantee you that anything which is supposed to hapen after you load Mime::Lite isn't actually happening. (Are you sending the email that you think you're sending?) If you think that it is, then I guarantee you that you are looking at one section of code and thinking that it did X when X is done in another section of code.

Incidentally the reasoning behind my guarantee is that fatalsToBrowser can only kick in, after you encountered a fatal error. That is, your program died, and the message that you see was its dying gasp.

Third I can tell you how to hide the errors. Just put eval around the statement that is causing error messages. That won't fix them, of course, but it sweeps them under the carpet. (Of course doing so liberally is a bad idea...)

I'm aware of the production code thing and switch it off in public, never fear. This code is production but only ever used by me so I like to keep it on so I know when things aren't ideal. Really, your guarantee is invalid. I do understand it's best to fix it and will spend some more time doing it but there are no last gasps, I can assure you. Something is obviously annoying Mime::Lite but it sends every mail perfectly and then the script carrys on fine and does lots of other stuff too. In fact, these errors appear at the very start, before anything has happened. Then stuff happens, then the emails are sent, then more stuff happens. So it's a funny type of error because it's not fatal but does appear when fatalstobrowser it is on. Thanks for the eval thing...

ugh.
when you see those errors -- fatal errors -- that means your script will most likely not function as advertised in certain, potentially critical points.

For you to not care that your code is coughing up these errors is sloppy. Why bother loading Mime::Lite if its dependencies aren't met?
Take everybody's advice and either satisfy Mime::Lite's requirements. When you say

I believe many of the modules that Mime::Lite uses are optional and I don't use them so I guess that why it works...

Well this is perhaps a tad unfair, brother. I know how my code works. If I comment out the 'require MIME::Lite' line then the errors don't happen. So I deduce that either MIME::Lite has a bug (extremely unlikely) or that my environment has some problem (pretty likely). My code has numerous problems, I have no doubt, but I don't think that these errors are caused by one of them.

So I deduce that either MIME::Lite has a bug (extremely unlikely)

Well, actually extremely is a bit stronger than I would say. Eryq is human, and so am I. In fact the whole reason I took over maintenance of the module was _because_ MIME::Lite had an error in it and Eryq didnt have the tuits to take care of it, so there was this buggy version in wide use. The 3.0 release was mostly a cosmetic change (with a few minor changes), the 3.01 release is the one to use. (Although I would be very grateful for people trying out the dev release of 3.01_03 especially if they are using authenticating SMTP servers for transmission, I wont release it with a "production" version number until I have feedback.)

But you are correct, MIME::Lite does try to use a bunch of modules and then falls back to roll-yer-own stuff if it cant find them. (Not my call, I probably wouldnt have done it that way myself, *shrug*) But you _shouldnt_ have been seeing the errors you did. Which is why i assume there is something strange about your setup. Please feel free to email me with more details so i can look into it closer if you do continue to experience problems. But please ensure you upgrade and check the various bits and bobs are up to date first. Also dont forget to send me your perl version, OS version and version of the module itself and any of the other modules that MIME::Lite uses.



---
demerphq



First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi