in reply to How to avoid "Use of uninitialized value" with printf?

Strings sent to STDERR (as from die or warnings) are interspersed with strings sent to STDOUT so errors and normal text may not be shown in the order that they are created. Very often error and warning messages are shown before the normal text that was generated around the time the error occurred.

One way to clean the issue up in this case is:

print join (' ', map {sprintf '%-12s', $_} @rows), "\n";

There are many other ways of course.

True laziness is hard work

Replies are listed 'Best First'.
Re^2: How to avoid "Use of uninitialized value" with printf?
by bobdabuilda (Beadle) on Apr 11, 2012 at 02:54 UTC

    GrandFather, thanks for the explanation and suggested fix. I'll take a look and do some reading up on the "print join" thing to work out how it works, then have a play with it in my code once I've sussed it out.

    I much prefer the option of avoiding the cause of the warnings, rather than simply suppressing them... never know what you're missing out on in the way of warnings you SHOULD be getting :)

      There are a number of interesting parts to that statement. The sprintf is just a printf that returns a string instead of sending it to a file.

      map processes lists. The expression inside the map is evaluated for each element in the list in turn with $_ aliased to the current element. A list containing the result of evaluating the expression for each element is returned by map.

      join just glues elements in a list together using the first string as glue.

      True laziness is hard work

      In this case, you (now) know that missing or undefined values (for the format string) are the cause of the warnings. Then, why not mute them for the relevant code for there is nothing else to "[miss] out on"?

      ... { no warnings 'uninitialized'; printf $format , @values; } ...

      Since missing values do not matter, both Not_a_Number's and Grandfather's suggestion will work equally.

      In case one would need to show the values under proper column headings, then you would need to fill in the missing or undefined values with substitute values (empty string, 0, -, N/A, /, etc). That may also call for the data to be properly formatted such that missing values are represented by their absence.

      Just wanted to report back to advise that I've now got this aspect of things working the way I wanted, with your help.

      I've also gone back over my code and tidied things up a bit and removed some of the superfluous variables I was using for reading in files, and gone back to using the default $_, which made things neater and has helped me to work out a couple other kinks.

      So, thanks again one and all for your assistance and suggestions :)

        To use or not to use $_ is often a hard call in the sense that there is often not a compelling reason to choose one technique over the other. However, I tend to use named variables in preference to uses of the default variable where the usage spans more than one statement. The default variable doesn't convey any sense of the use it is being put to whereas a well named variable can add a great deal to understanding code.

        "Neater" can mean a great many things, but "long term maintainable" is generally a much more desirable objective.

        True laziness is hard work