Re: Eval Errors

WC -Sx- Jones wrote: > James Edward Gray II wrote: > > Note that ALL warnings are explicitly disabled and the program is no > > longer printing the error messages yet the strange messages remain. > > Also note that the program does reach the final print. > > > > Those messages are fatal errors tha

Re: Eval Errors

On Feb 24, 2004, at 10:13 AM, WC -Sx- Jones wrote: IIRC it was determined then that 'eval' focus was to allow testing of trappable events - without allowing the code (however crazy) to die. The side effects are such that there are tests which lead one to believe X is a bug when in fact it is a

Re: Eval Errors

James Edward Gray II wrote: Note that ALL warnings are explicitly disabled and the program is no longer printing the error messages yet the strange messages remain. Also note that the program does reach the final print. Those messages are fatal errors that just don't happen to kill the program

Re: Eval Errors

On Feb 24, 2004, at 9:10 AM, Rafael Garcia-Suarez wrote: This prints nothing but "Exiting normally" with blead; and now that you mention it... this was already reported as a bug (#24815) and was fixed by change #22068. For the sake of closure, this is the official answer, buried in a little jargo

Re: Eval Errors

James Edward Gray II wrote: > > On Feb 24, 2004, at 8:46 AM, Rafael Garcia-Suarez wrote: > > >> But since it's inside an eval() call, those messages should get stuck > >> in $@ and NOT printed. As Randy has said, they would kill a normal > >> program, if they were in the source. They are not war

Re: Eval Errors

On Feb 24, 2004, at 8:46 AM, Rafael Garcia-Suarez wrote: But since it's inside an eval() call, those messages should get stuck in $@ and NOT printed. As Randy has said, they would kill a normal program, if they were in the source. They are not warnings. Nope. They are warnings, except that they

Re: Eval Errors

James Edward Gray II wrote: > >> Bareword found where operator expected at (eval 2) line 1, near "'a > >> poorly 'nested::nested" > >> (Missing operator before nested::nested?) > >> String found where operator expected at (eval 2) line 1, near > >> "nested::nested' string'" > >> Caught: sy

Re: Eval Errors

On Feb 24, 2004, at 3:17 AM, Rafael Garcia-Suarez wrote: Randy W. Sims wrote: I've CC'd p5p for enlightenment & simplified your code to the following: my @code = ( q('a poorly 'nested' string'), q('a poorly 'nested::nested' string'), ); for (@code) { eval; print "Caught: $@" if $@; }

Re: Eval Errors

On Feb 23, 2004, at 11:16 PM, WC -Sx- Jones wrote: James Edward Gray II wrote: eval() shouldn't be squawking there, as I understand it. Those look like die() statements to me too, yet the program keeps running. Hmm. I dont know - I believe we are missing something basic prolly: # My Version

Re: Eval Errors

Randy W. Sims wrote: > > If I give perl the program: > > 'a 'nested' string' > > I get the first error above, which is a compile time error. No code is > executed. It's tokenized as : string literal : 'a ' identifier : nested' and then it expects the rest of the identifier, doesn't see i

Re: Eval Errors

On 02/24/04 04:17, Rafael Garcia-Suarez wrote: Randy W. Sims wrote: I've CC'd p5p for enlightenment & simplified your code to the following: my @code = ( q('a poorly 'nested' string'), q('a poorly 'nested::nested' string'), ); for (@code) { eval; print "Caught: $@" if $@; } Output is: Ca

Re: Eval Errors

Randy W. Sims wrote: > > I've CC'd p5p for enlightenment & simplified your code to the following: > > my @code = ( >q('a poorly 'nested' string'), >q('a poorly 'nested::nested' string'), > ); > > for (@code) { >eval; >print "Caught: $@" if $@; > } > > Output is: > > Caught: Bad

Re: Eval Errors

Randy W. Sims wrote: I've CC'd p5p for enlightenment & simplified your code to the following: ... I understand the errors, but not the difference in behaviour. I think this is DWIMish bug in perl, but let's see what more enlightened minds say before reporting it as such. My money is on no wa

Re: Eval Errors

James Edward Gray II wrote: eval() shouldn't be squawking there, as I understand it. Those look like die() statements to me too, yet the program keeps running. Hmm. I dont know - I believe we are missing something basic prolly: # My Version - #!/usr/bin/perl use strict; use warnings; m

Re: Eval Errors

I've CC'd p5p for enlightenment & simplified your code to the following: my @code = ( q('a poorly 'nested' string'), q('a poorly 'nested::nested' string'), ); for (@code) { eval; print "Caught: $@" if $@; } Output is: Caught: Bad name after nested' at (eval 1) line 1. Bareword found where

Re: Eval Errors

On Feb 23, 2004, at 9:31 PM, Charles K. Clarkson wrote: : Disabling warnings... : Calling eval()... : Bareword found where operator expected at (eval 3) line 1, near "'a : poorly 'nested::test" : (Missing operator before nested::test?) : String found where operator expected at (eval 3) li

RE: Eval Errors

James Edward Gray II <[EMAIL PROTECTED]> wrote: : [snipped code] : : Interesting things to note about the above: All three @strings are : bad perl code and don't compile. Warnings are disabled when I run : the eval() and thus, not a part of the equation. (The script runs : identically if the

Re: Eval Errors

On Feb 23, 2004, at 8:51 PM, WC -Sx- Jones wrote: OK, after correcting the smiley error (Grrr again) the outout I get is: You're seeing the same thing I am. Calling eval()... Bareword found where operator expected at (eval 3) line 1, near "'a poorly 'nested::test" (Missing operator befor

Re: Eval Errors

OK, after correcting the smiley error (Grrr again) the outout I get is: Code: my $bad_syntax = ; Disabling warnings... Calling eval()... eval() complete. Handling error... Caught error: syntax error at (eval 1) line 1, at EOF Code: 'a poorly 'nested' string' Disabling warnings... Calling eval

Re: Eval Errors

On Feb 23, 2004, at 8:37 PM, WC -Sx- Jones wrote: James Edward Gray II wrote: Are you suggesting that the script I posted does not pass a compile check? It does on my machine. Yep. Well, I think you're wrong. ;) The "bug" I'm talking about is how eval() prints what looks like die() messages

Re: Eval Errors

James Edward Gray II wrote: my @strings = ( q(my $bad_syntax = ;), The ;) was converted to a smiley on my system. G... -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eval Errors

James Edward Gray II wrote: Are you suggesting that the script I posted does not pass a compile check? It does on my machine. Yep. The "bug" I'm talking about is how eval() prints what looks like die() messages (though it keeps running) when it tries to compile the third line. There's a deta

Re: Eval Errors

James Edward Gray II wrote: >> >> __END__ What are you saying? Its not a bug - it doesn't pass perl -c progname it passed on my machine v5.8.0 built for i386-linux-thread-multi root$> perl -c test.pl test.pl syntax OK not sure what that means to the overall conclusion Cheers! -Sx

Re: Eval Errors

On Feb 23, 2004, at 8:28 PM, WC -Sx- Jones wrote: James Edward Gray II wrote: __END__ What are you saying? Its not a bug - it doesn't pass perl -c progname Are you suggesting that the script I posted does not pass a compile check? It does on my machine. The "bug" I'm talking about is how e

Re: Eval Errors

James Edward Gray II wrote: __END__ What are you saying? Its not a bug - it doesn't pass perl -c progname Cheers! -Sx- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Eval Errors

On Feb 23, 2004, at 2:21 PM, James Edward Gray II wrote: #!/usr/bin/perl use strict; use warnings; my @strings = ( q(my $bad_syntax = ;), q('a poorly 'nested' string'), q('a poorly 'nested::test' string') ); foreach (@strings) {

Re: Eval Errors

On Feb 23, 2004, at 2:39 PM, david wrote: James Edward Gray II wrote: On Feb 23, 2004, at 10:35 AM, James Edward Gray II wrote: I believe I have a solution now. I'm going to try switching the way the system works to eval() to a hash reference, instead of a hash. I expect that to silence the tw

Re: Eval Errors

As several have pointed out now, my description of the problem was involved. Sorry about that. I was showing you a tiny slice of the 3,000 line server where I know the problem is occurring. However, thanks to the help provided, I managed to simplify the problem to a small script. We can talk

Re: Eval Errors

On Feb 23, 2004, at 1:28 PM, Randy W. Sims wrote: On 02/23/04 14:18, James Edward Gray II wrote: On Feb 23, 2004, at 12:59 PM, Randy W. Sims wrote: The string form of eval does not catch errors. You sure about that? 'perldoc -f eval' doesn't seem to agree with this and when I run: My bad. The do

Re: Eval Errors

James Edward Gray II wrote: > On Feb 23, 2004, at 10:35 AM, James Edward Gray II wrote: > >> I believe I have a solution now. I'm going to try switching the way >> the system works to eval() to a hash reference, instead of a hash. I >> expect that to silence the two original warnings caused by

Re: Eval Errors

On 02/23/04 14:18, James Edward Gray II wrote: On Feb 23, 2004, at 12:59 PM, Randy W. Sims wrote: The string form of eval does not catch errors. You sure about that? 'perldoc -f eval' doesn't seem to agree with this and when I run: My bad. The docs for eval do say that $SIG{__WARN__} is the on

Re: Eval Errors

On Feb 23, 2004, at 12:59 PM, Randy W. Sims wrote: The string form of eval does not catch errors. You sure about that? 'perldoc -f eval' doesn't seem to agree with this and when I run: perl -we 'eval q(my $bad_syntax = ;); if ($@) { print "Caught error.\n" }' I get: Caught error. Also, you

Re: Eval Errors

On 02/23/04 11:56, James Edward Gray II wrote: On Feb 23, 2004, at 10:35 AM, James Edward Gray II wrote: I believe I have a solution now. I'm going to try switching the way the system works to eval() to a hash reference, instead of a hash. I expect that to silence the two original warnings cau

Re: Eval Errors

On Feb 23, 2004, at 10:35 AM, James Edward Gray II wrote: I believe I have a solution now. I'm going to try switching the way the system works to eval() to a hash reference, instead of a hash. I expect that to silence the two original warnings caused by the undef being returned. More egg on m