Hi Shmuel! Yes what you suggest works. Thanks again!
Meir From: Perl [mailto:[email protected]] On Behalf Of Shmuel Fomberg Sent: יום ה 31 יולי 2014 19:27 To: Perl in Israel Subject: Re: [Israel.pm] Not understood behavior of 'eval' --- Solved Hi Meir. So I was mistaken. mostly because usually when talking about retrieving data, people mean retrieving it from the DB, not from perl itself. Anyway, you eval line: my $raw_string_1 = '{return "WHERE col = \'$sql_date\'"}'; eval $raw_string_1; is equal to: my $raw_string_1 = '"WHERE col = \'$sql_date\'"'; eval $raw_string_1; as the string itself is a valid perl. you don't need to wrap it in more syntax. and is equal to simply: "WHERE col = '$sql_date'"; as you are using eval to activate perl's string interpolation. I can speculate that you are using this technique to imitate named references, and passing them to a function that should 'fill the blanks'. Let's call it 'delayed string interpolation'? :-) well, it can work in a pinch, as long as you are sure that your data don't have anything strange. But still, if this thing will grew a bit, I'd recommend rethinking the approach. Shmuel. On Fri, Aug 1, 2014 at 1:12 AM, Meir Guttman <[email protected]> wrote: Dear Shmuel, Yes, I am well aware that I am using Perl’s ‘eval’! And no, $dbh->do() cannot be used to retrieve data. But I had my share of the RTFM syndrom L. The very first line of the ‘eval’ page in perldoc is: In the first form, the return value of EXPR is parsed and executed as if it were a little Perl program. (my enhancement.) So I changed case #1 to be: my $raw_string_1 = '{return "WHERE col = \'$sql_date\'"}'; That when eval’ed, yielded: WHERE col = '2014-7-31' As required. Sorry folks to bother you Meir From: Perl [mailto:[email protected]] On Behalf Of Shmuel Fomberg Sent: יום ה 31 יולי 2014 18:22 To: Perl in Israel Subject: Re: [Israel.pm] Not understood behavior of 'eval' Hi Meir. I think that you are confusing perl's eval and DBI eval. Your code is using perl's eval, which is invalid for #1, (so you get undef and can check $@ for error string) and for #2, the evaluated string is $sql_date, so you get the date inside it. if you want to have SQL command to the DB, check the DBI module: https://metacpan.org/pod/DBI I think you are looking for the 'do' command. Shmuel. On Fri, Aug 1, 2014 at 12:15 AM, Meir Guttman <[email protected]> wrote: Please Perlers, The following script: <code> use strict; use warnings; my $sql_date = '2014-7-31'; my $raw_string_1 = 'WHERE col = $sql_date'; my $raw_string_2 = '$sql_date'; my $evaled_1 = eval $raw_string_1; # yields 'undef' my $evaled_2 = eval $raw_string_2; # yields '2014-7-31' print "First: $evaled_1\nSecond: $evaled_2\n"; </code> Yields 'undef' (and a concatenation warning) for $evaled_1 and '2014-7-31' for $evaled_2. Why??? Notes: 1) I need the first form to work. 2) I am well aware of the DBI/DBD 'prepare()' with place holders. Mine is not the case for it, since 'col' is a run-time column name and so it cannot be assigned a place holder. 3) Neither can the date be assigned to a place holder. It is not always a date. The "WHERE" clause is an arbitrary complex compilation read from an INI file and various parts in it must be substituted by Perl variables values, also only determined at run-time. Thanks! Meir _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
_______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
