I have encountered a very strange thing, and I'm wondering if anyone else has seen it, and if so what he or she might have done about it. The most frustrating aspect of this is that I cannot reproduce the problem with a short program that contains the same code.

As background, allow me to say that I've been working with Perl for some 20 years. I'm not a newbie, and I've eliminated many possibilities already. I'm open to the possibility that I'm missing something fundamental, but I'm as certain as a person can be that it's nothing basic.

The code is thus:

...
$baz = $info{$key};
# $baz = unpack('H*', $baz);
# $baz =   pack('H*', $baz);
print(STDOUT '[' . ($baz)               . "]\n");
print(STDOUT '[' . (unpack('H*', $baz)) . "]\n" );
print(STDOUT '[' . ($baz eq 'true')     . "]\n");
print(STDOUT '[' . ($baz eq 'false')    . "]\n");
print(STDOUT '[' . ($baz eq 'default')  . "]\n");
...

[download]

With those unpack() and pack() calls commented out and when the value of $info{$key} is 'false' (that is, the string 'false'), the code in-place in the larger program yields:

[false]
[66616c7365]
[]
[1]
[1]

[download]

When I remove the comment markers (thus calling unpack() and then pack() in succession on the value), it yields the much more expected:

[false]
[66616c7365]
[]
[1]
[]

[download]

Again, if I take these lines and make them into a short program by themselves, the unpack() / pack() dance is not necessary; the three 'eq' comparisons yield the second block of output, as expected.

So, we have a situation where (a) 'eq' is evaluating the same value to be equivalent to two different strings, and (b) an unpack() followed immediately by pack() is having an effect on the value, when that should not happen (at least, not with a template as simple as 'H*') since these two functions are mirrors of each other.

Has anyone ever seen the same kind of unexpected funniness with 'eq'? Does the fact that unpack() + pack() affects the value here tell us anything about the nature of the underlying data that is salient to understanding the unexpected 'eq' results? And, related, is there something about the inner operation of unpack() / pack() that sheds some light on this oddity?

Thanks in advance for any insight. I'm happy to provide additional detail that might help diagnose this.

In reply to eq evaluates a variable as equal to two different strings by landru27

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.