http://www.perlmonks.org?node_id=682560

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

Here is my code:
sub test2{ return "HTML"; } sub test { return join '', test2("1", "$ENV{'HTTP_HOSTS'} "); } print test();
And here is the result:
C:\WINDOWS\system32\cmd.exe /c sh $ perl -w test.PL Use of uninitialized value in concatenation (.) or string at test.PL l +ine 11. HTML$
I am using perl, v5.8.3 built for MSWin32-x86-multi-thread. The second argument passed to test2 is undef, but why would that cause this error? Notice that test2 still returns "HTML". And how best to correct this error?

Replies are listed 'Best First'.
Re: Why does an undef argument in a join produce this warning?
by wfsp (Abbot) on Apr 24, 2008 at 06:14 UTC
    The second argument is not undef. The double quotes
    "$ENV{'HTTP_HOSTS'} "
    says that you are trying to concatanate an undef value with, in this case, a space. That is what Perl is complaining about. Remove the quotes and the result is
    HTML
    nit: You don't need the quotes around the hash key either.
      Thanks. you and chromatic were right
        You already have the solution for this case. If you ever have issues with unwanted warnings again, you should know that there can be specifically deactivated locally in the current scope.

        E.g. if you know that one function can cause this warning and the only way around would be massive use of if defined you can just say no warnings 'uninitialized'; to tell Perl that you don't want this specific warning inside the current scope, i.e. sub function or { } block, etc.

Re: Why does an undef argument in a join produce this warning?
by chromatic (Archbishop) on Apr 24, 2008 at 06:12 UTC

    Interpolating a variable containing an uninitialized value into a string produces that warning if you have warnings enabled. Remove the double quotes and the warning will disappear. join has nothing to do with it.

      But sometimes I need to interpolate that value and pass it to the test2 sub. Hmmm... perhaps I could check if the variable is not defined before passing to the sub.