in reply to Re: Re: v-string in use/require non-portable
in thread v-string in use/require non-portable

Hugo, Thanks for your help. I will try the ways you suggested. Do you think if I do what you suggested me to do, this will make my perl script run correctly. The script was running correctly before, after I install MailTool module, it can not run and give a error message: "Unrecoginzed lines '1001@151.104.234.7'" in the method MIME::Lite->new. So previously running script now can not run anymore. Do you think how I can slove this problem? Thanks again, Quency
  • Comment on Re: Re: Re: v-string in use/require non-portable

Replies are listed 'Best First'.
Re: Re: Re: Re: v-string in use/require non-portable
by hv (Prior) on May 16, 2004 at 21:29 UTC

    I would doubt this fix will make your program work correctly, since all it is doing is suppressing an otherwise irrelevant warning. (And please note the correct version of that workaround supplied in the comment from ysth.)

    I would suspect that as a result of installing MIME::Parser, a simpler heuristic for validating an email address has been replaced with something that tries to be more precise, but in the process loses the ability to cope with IP address as domain.

    One possible approach (which might be a good idea anyway) would be to replace the dotted IP addresses with names. However there are reasons you might be unable or unwilling to do that.

    My guess is that the error message is coming from Mail::Address->_tokenise(), called by parse(), but I haven't analysed the code to determine why it is giving the error: certainly a standalone attempt to parse the same string seems quite happy:

    perl -MMail::Address -wle 'print Mail::Address->parse("1002\@151.104 +.234.7")' Mail::Address=ARRAY(0x815a8bc)
    .. showing that it returns a single Mail::Address object. (Does it do the same for you?)

    Beyond that I can think of no obvious reason for a problem. One possible approach is to install a duplicate of the relevant modules in a space somewhere under your control, and add diagnostics (or use the debugger) to track down precisely where the problem occurs and why. Once you've gained that understanding, you should be able to determine whether it is a problem with your own code or with that in one of the modules, and resolve it either by fixing your code or supplying a rationale and patch to the relevant module maintainer and waiting for a new release.

    Assuming I'm correct about the source of the error message, the starting point would be the one place in the code that mentions Mail::Address, where depending on whether the module can be loaded one of two versions of each of two subroutines is installed: extract_full_addrs() and extract_only_addrs().

    (Indeed, this suggests one possible workaround, to subclass MIME::Lite and overload those two subroutines to point to the fallback methods:

    { package My::MIME::Lite; use MIME::Lite; our @ISA = qw/ MIME::Lite /; *extract_full_addrs=*MIME::Lite::my_extract_full_addrs; *extract_only_addrs=*MIME::Lite::my_extract_only_addrs; } $mime_msg = My::MIME::Lite->new(...); My::MIME::Lite->send(...); $mime_msg->send();
    .)

    Hugo

      I think youll find that alas this wont work. MIME::Lite is a hybrid OO/and imperative so extract_XXXX_addrs() are called procedurally from the methods in MIME::Lite so will no actually end up using the new ones. (A good argument for NOT doing this type of hybridization IMO.) In fact its arguable I should change this so that this type of thing is easier.


      ---
      demerphq

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