in reply to v-string in use/require non-portable

I have seen this before
v-string in use/require non-portable at /usr/lib/perl5/site_perl/5.8.0/MIME/Field/ParamVal.pm line 65.
and I think it's just a grumble or a warning you can ignore. Try removing any -w flags and it will probably go away. As for the other error, which looks more serious, I don't know. Good luck,
Andy.

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

    The warning is coming from this line of Mail::Field::ParamVal:

    require v5.6;

    Such a line no longer causes a warning in more recent perls, but you can avoid the problem either by modifying the above line to read:

    require 5.006;
    or with something like this in your own code:
    BEGIN { no warnings 'portable'; require Mail::Field::ParamVal; }
    .. to make sure the offending module is loaded and compiled early, with that particular warning disabled.

    Beware that taking the latter approach has a small chance of causing you problems in the future, if a later version of perl detects some other portability problem in the module that you would have wanted to know about.

    The other workaround, of course, is to upgrade to the latest maintenance version of perl 5.8, currently 5.8.4.

    Hugo

      I don't think that workaround will work; since the "no warnings" is lexically scoped, it will have no effect on ParamVal.pm.

      MIME::Field::ParamVal doesn't use warnings itself, so it is only warning because the original poster running using the -w switch (or is turning on warnings with the $^W variable.) Removing the -w and putting "use warnings" in the main script instead should fix the problem (by disabling any warnings from all modules that didn't explicitly enable them), as would:

      BEGIN { local $^W = 0; require MIME::Field::ParamVal; }
      Incidentally, this warning is removed as of 5.8.1, but is still in bleadperl; is this intentional?

        I don't think that workaround will work

        Oops, my bad. Indeed, your suggested mechanism should work far better.

        Incidentally, this warning is removed as of 5.8.1, but is still in bleadperl; is this intentional?

        I would expect so, but I'd have to check back through the voluminous discussions around this to be certain. I think the intention is that in 5.10 the various v-string syntaxes will generate a version object, and require VERSION; will simply DTRT.

        Hugo

      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

        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