in reply to Re: Re: when is a string not a string?
in thread when is a string not a string?

While I suspect there is some more pragmatic answer, you might get that kind of behaviour from passing an overloaded object to the code (f ex something that overloads stringifying and concatenation and makes a poor job at it), or some tied variable, I guess. What are you passing to this sub, anyway? (Obscure reference: It is not $2, is it?)

Unless you are passing something you know to be strange magic, I would have another look at how this passed value behaves. Like this, perhaps:

my $passed_sql = shift; my $sql = "SELECT COUNT(*) etc blah blah"; print STDERR "Trying[1] to print parameter alone: " print STDERR $passed_sql; print STDERR "\nTrying[2] list print: ", $passed_sql; print STDERR "\nTrying[3] interpolated: $passed_sql\n"; die if $sql ne $passed_sql; # Might as well ... my ($total_cols) = $dbh->selectrow_array($sql) or die($dbh->errstr +);

Again, I expect the problem is easier (and might be fixed alread?), but if not, I hope this helps.

The Sidhekin
print "Just another Perl ${\(trickster and hacker)},"

Replies are listed 'Best First'.
Re: Re: Re: Re: when is a string not a string?
by Anonymous Monk on May 03, 2002 at 16:20 UTC
    Thanks for all the replies to date, very helpful, I will find the person who wrote it and find out exactly how he is calling it...

    I'm completely confused as to what is going on, if I use the die statement as written by tachyon it fails, and doesn't interpolate the variable $sql, but if I just die $sql it prints perfectly. The behaviour is baffling to say the least.

    I'll resume the discussion on tueday after a nice long rest (bank holiday here in uk)

    Thanks a lot for help up to now!
      Try using something besides single quotes to print boundaries around the variable -- typically the expression '$variable' does not interpolate to the value of $variable.
Re: Re: Re: Re: when is a string not a string?
by purge (Acolyte) on May 07, 2002 at 08:47 UTC
    I've just returned to this problem today and, tada, it looks like it is $2 that is being passed! now why would I get this behaviour in this case?

    Thanks for all the replies, I think we are about to crack this problem!

      tada, it looks like it is $2 that is being passed!

      That was a long shot! There is (or was?) a bug in perl, so that $2 was not properly bound, and would evaluate to undef if first evaluated outside the scope of the regex that set it. (And passing to a function did not, for the purposes of this bug, count as "evaluating" it.)

      I guess this is the bug that bit you. It is an easy bug to work around. All you need is to assign some dummy variable my $dummy = $2. Or maybe you could even get around it by passing "$2" instead of $2 to the function. I don't remember the details.

      The Sidhekin
      print "Just another Perl ${\(trickster and hacker)},"