Re: Eval scoping question

On Dec 11, 10:52 am, rvtol+use...@isolution.nl (Dr.Ruud) wrote: > C.DeRykus wrote: > > Dr.Ruud: > >> C.DeRykus: > >>>      eval { asub() }; > >>>      die $@ if $@; > > >> You need to test the return of eval itself to be sure. > > ... > perl -wle ' > >    die "An error: ", $@ || "whoopy" >      i

Re: Eval scoping question

C.DeRykus wrote: Dr.Ruud: C.DeRykus: eval { asub() }; die $@ if $@; You need to test the return of eval itself to be sure. Example: perl -wle ' die "An error: ", $@ || "whoopy" if !eval{ asub(); 1 }; sub asub{ my $x = bless {}, "main"; 1 / 0 } sub DESTROY{ $@ =

Re: Eval scoping question

On Dec 10, 1:21 pm, rvtol+use...@isolution.nl (Dr.Ruud) wrote: > C.DeRykus wrote: > > On Dec 8, 1:57 am, dery...@gmail.com (C.DeRykus) wrote: > >> On Dec 8, 12:08 am, an...@melerit.se (Anders Hartman) wrote: > >> Also, in this case, I'd write the eval for compile-time and check > >> for errors: > >

Re: Eval scoping question

On Dec 10, 12:57 pm, shawnhco...@gmail.com (Shawn H Corey) wrote: > C.DeRykus wrote: > > On Dec 8, 1:57 am, dery...@gmail.com (C.DeRykus) wrote: > >> On Dec 8, 12:08 am, an...@melerit.se (Anders Hartman) wrote: > > >>> ... > > >> ... > >> Also, in this case, I'd write the eval for compile-time and

Re: Eval scoping question

C.DeRykus wrote: On Dec 8, 1:57 am, dery...@gmail.com (C.DeRykus) wrote: On Dec 8, 12:08 am, an...@melerit.se (Anders Hartman) wrote: Also, in this case, I'd write the eval for compile-time and check for errors: eval { asub() }; die $@ if $@; No, sorry, that's a "useless use of

Re: Eval scoping question

C.DeRykus wrote: > On Dec 8, 1:57 am, dery...@gmail.com (C.DeRykus) wrote: >> On Dec 8, 12:08 am, an...@melerit.se (Anders Hartman) wrote: >> >>> ... > >> ... >> Also, in this case, I'd write the eval for compile-time and check >> for errors: >> >> eval { asub() }; >> die $@ if $@; >> >

Re: Eval scoping question

On Dec 8, 1:57 am, dery...@gmail.com (C.DeRykus) wrote: > On Dec 8, 12:08 am, an...@melerit.se (Anders Hartman) wrote: > >> ... > ... > Also, in this case, I'd write the eval for compile-time and check > for errors: > >      eval { asub() }; >      die $@ if $@; > No, sorry, that's a "useless us

Re: Eval scoping question

On Dec 8, 12:08 am, an...@melerit.se (Anders Hartman) wrote: > Hello, > > I which to use eval to execute subroutines dynamically. > > The following code snippet fails: > > #!/usr/bin/perl > > use strict; > use warnings; > > sub asub { >    our $abc; >    print $abc; > > } > > my $abc = "abc\n"; > e

Re: Aw: Re: Eval scoping question

pa...@arcor.de wrote: > Well, the OP said the method name is changing during the running time, so he > want to eval the method name. > So a AUTOLOAD method is right for him as far as I can think. AUTOLOAD introduces the possibility of code injection. So does eval. If the code is running on a ser

Aw: Re: Eval scoping question

- Original Nachricht Von: Shlomi Fish An: beginners@perl.org Datum: 08.12.2009 12:08 Betreff: Re: Eval scoping question > On Tuesday 08 Dec 2009 12:18:10 Jeff Pang wrote: > > Shlomi Fish: > > > On Tuesday 08 Dec 2009 11:46:59 Jeff Pang wrote:

Re: Eval scoping question

On Tuesday 08 Dec 2009 12:18:10 Jeff Pang wrote: > Shlomi Fish: > > On Tuesday 08 Dec 2009 11:46:59 Jeff Pang wrote: > >> Shlomi Fish: > >>> Regarding using string eval "" - you can do the same using > >>> UNIVERSAL::can, which would be safer in this case: > >>> > >>> > >>> __PACKAGE__->can("a

Re: Eval scoping question

Shlomi Fish: On Tuesday 08 Dec 2009 11:46:59 Jeff Pang wrote: Shlomi Fish: Regarding using string eval "" - you can do the same using UNIVERSAL::can, which would be safer in this case: __PACKAGE__->can("asub")->(@params); or define a package and use AUTOLOAD method? How will the AUTOL

Re: Eval scoping question

On Tuesday 08 Dec 2009 11:46:59 Jeff Pang wrote: > Shlomi Fish: > > Regarding using string eval "" - you can do the same using > > UNIVERSAL::can, which would be safer in this case: > > > > > > __PACKAGE__->can("asub")->(@params); > > or define a package and use AUTOLOAD method? > How will

Re: Eval scoping question

Shlomi Fish: Regarding using string eval "" - you can do the same using UNIVERSAL::can, which would be safer in this case: __PACKAGE__->can("asub")->(@params); or define a package and use AUTOLOAD method? -- Jeff Pang http://home.arcor.de/pangj/ -- To unsubscribe, e-mail: beginner

Re: Eval scoping question

2009/12/8 Anders Hartman : >>> Hello, >>> I which to use eval to execute subroutines dynamically. >>> The following code snippet fails: >>> >>> #!/usr/bin/perl >>> >>> use strict; >>> use warnings; >>> >>> sub asub { >>>  our $abc; >>>  print $abc; >>> } >>> >>> my $abc = "abc\n"; >>> eval "asub";

Re: Eval scoping question

On Tuesday 08 Dec 2009 11:03:44 Anders Hartman wrote: > Jeff Pang skrev: > > Anders Hartman: > >> Hello, > >> > >> I which to use eval to execute subroutines dynamically. > >> > >> The following code snippet fails: > >> > >> > >> #!/usr/bin/perl > >> > >> use strict; > >> use warnings; > >> > >> su

Re: Eval scoping question

Jeff Pang skrev: Anders Hartman: Hello, I which to use eval to execute subroutines dynamically. The following code snippet fails: #!/usr/bin/perl use strict; use warnings; sub asub { our $abc; print $abc; } my $abc = "abc\n"; eval "asub"; exit 0; I don't think you want an eval here

Re: Eval scoping question

Anders Hartman: Hello, I which to use eval to execute subroutines dynamically. The following code snippet fails: #!/usr/bin/perl use strict; use warnings; sub asub { our $abc; print $abc; } my $abc = "abc\n"; eval "asub"; exit 0; I don't think you want an eval here. use strict; use

Re: eval and next

Date sent: Tue, 06 Oct 2009 15:45:44 +0200 From: Alexander Koenig To: beginners Subject:eval and next > Hi all, > > I have a Perl program where I use eval to catch errors. As they are Java > errors (via Inline::Java) I want my p

Re: eval and script performance ?

Deviloper wrote: The last time I considered using eval is years ago. I remember that I had read an article somewhere that doing eval could lead to dramatic performance issues. I want to use eval{} to check my db-transactions. I looking for informations at perldoc eval, but there is nothing me

Re: eval and script performance ?

On Thu, Oct 16, 2008 at 12:38:54PM +0100, Deviloper wrote: > The last time I considered using eval is years ago. I remember that I > had read an article somewhere that doing eval could lead to dramatic > performance issues. > > I want to use eval{} to check my db-transactions. I looking for > in

Re: Eval not working on code

On 3/22/07, Kevin Old <[EMAIL PROTECTED]> wrote: Not sure why eval isn't working. Nothing is returned if I print $@ after the eval statement. What do you mean whan you say eval "isn't working"? What is it doing? Does it run any of the code? The code you included doesn't print or check $@ afte

Re: Eval Questions with blocks

The general form for block eval is: #!/usr/bin/perl use strict; use warnings; eval { die 'There was an error!!!' . "\n"; }; if ($@) { print $@; } print 'On the other side.' . "\n"; Robert On Feb 19, 2007, at 4:13 PM, Gallagher, Tim F ((NE)) wrote: I am working my butt off trying

RE: eval problem

On Tue, 27 Jun 2006, Smith, Derek wrote: So could this `$SIG{'PIPE'}="IGNORE";' be considered a global similar to $ENV{"PATH"} = qq(/opt/SUNWsamfs/sbin:/usr/bin); Yes, %SIG is a global hash. Jorge -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED

RE: eval problem

-Original Message- From: Jorge Almeida [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 27, 2006 9:37 AM To: John W. Krahn Cc: Perl Beginners Subject: Re: eval problem On Tue, 27 Jun 2006, John W. Krahn wrote: > Jorge Almeida wrote: >> What is happening? > > When find

Re: eval problem

On Tue, 27 Jun 2006, John W. Krahn wrote: Jorge Almeida wrote: What is happening? When find dies a SIGPIPE signal is sent to the parent process which kills it. Thank you. Putting `$SIG{'PIPE'}="IGNORE";' in the beginning of my program solves my problem. Jorge -- To unsubscribe, e-mail

Re: eval problem

Jorge Almeida wrote: > Can someone help me to understand what's wrong with this? (Or: what I > didn't understand about eval?) > > $ perl -e 'use strict;use warnings;eval{open(OUT,"|file")};eval{print > OUT "aa\n";};eval{close OUT};;' > Usage: file [-bcikLnNsvz] [-f namefile] [-F separator] [-m mag

Re: eval{}

On 3/7/06, Chas Owens <[EMAIL PROTECTED]> wrote: > On 3/7/06, Jay Savage <[EMAIL PROTECTED]> wrote: > snip > > Since eval traps die, 'eval{ eval {} or die [EMAIL PROTECTED];};' is a > > convenient > > method for propagating $@ out of deeply nested evals. It's just a way > > to save writing lots of

Re: eval{}

On 3/7/06, Jay Savage <[EMAIL PROTECTED]> wrote: snip > Since eval traps die, 'eval{ eval {} or die [EMAIL PROTECTED];};' is a > convenient > method for propagating $@ out of deeply nested evals. It's just a way > to save writing lots of if blocks that do nothing but pass $@ along. snip You had b

Re: eval{}

On 3/6/06, Tom Allison <[EMAIL PROTECTED]> wrote: > Jay Savage wrote: > > > > > die on errors and just keep passing them up the line: > > > > eval { > > eval { > > eval { > > bad_system_call() or die "$!\n"; > > } or die $@; > > } or die $

Re: eval{}

On 3/6/06, Tom Allison <[EMAIL PROTECTED]> wrote: > Will 'die' by itself propogate the contents of $@ ad infinitum? Well, not ad infinitum. But it will propagate, according to perldoc's entry on die(). Cheers! --Tom Phoenix Stonehenge Perl Training -- To unsubscribe, e-mail: [EMAIL PROTECTED] F

Re: eval{}

Jay Savage wrote: die on errors and just keep passing them up the line: eval { eval { eval { bad_system_call() or die "$!\n"; } or die $@; } or die $@; }; print "eval says: [EMAIL PROTECTED]" if $@; As long as you keep propa

Re: eval{}

On 3/6/06, Tom Allison <[EMAIL PROTECTED]> wrote: > > I ran into a potential problem when writing some code this weekend. > > I'm running a network socket to pick up data and then run it against a > database connection before I return the response. Essentially it falls > into a few steps: > > read

Re: eval{}

On 3/6/06, Tom Allison <[EMAIL PROTECTED]> wrote: > The problem I run into is throwing the exceptions up to the top eval{} > structure when I need to communicate that something didn't work right > so I can provide feedback to the network client connection. > > I suppose I could try and rewrite the

Re: eval without warnings

> On Sep 27, Bryan R Harris said: > >> "2*(3+2)" ==> 10 >> "2*dog" ==> "2*dog" >> "mysquarefunction(2)" ==> 4 >> "3*mysquarefunction(2)" ==> 12 >> "some guy" ==> "some guy" > > Here's a solution that works for the cases you've provided: > >sub try_eval { > local $@; > my $warning

Re: eval without warnings

On Sep 27, Bryan R Harris said: "2*(3+2)" ==> 10 "2*dog" ==> "2*dog" "mysquarefunction(2)" ==> 4 "3*mysquarefunction(2)" ==> 12 "some guy" ==> "some guy" Here's a solution that works for the cases you've provided: sub try_eval { local $@; my $warning; local $SIG{__WARN__} = sub

Re: eval without warnings

> On Tue, 27 Sep 2005, Bryan R Harris wrote: > >> I'd like to evaluate user input only where it makes sense, e.g. >> >> "2*(3+2)" ==> 10 >> "2*dog" ==> "2*dog" >> "mysquarefunction(2)" ==> 4 >> "3*mysquarefunction(2)" ==> 12 >> "some guy" ==> "some guy" > > What happens when they put somethin

Re: eval without warnings

On Tue, 27 Sep 2005, Bryan R Harris wrote: > I'd like to evaluate user input only where it makes sense, e.g. > > "2*(3+2)" ==> 10 > "2*dog" ==> "2*dog" > "mysquarefunction(2)" ==> 4 > "3*mysquarefunction(2)" ==> 12 > "some guy" ==> "some guy" What happens when they put something in like "sys

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 Reasons?

James Edward Gray II wrote: On Feb 24, 2004, at 12:21 AM, WC -Sx- Jones wrote: Now there aren't any errors: I believe/hope you are kidding here, ... Yes, I was teasing. The code is a trigger which is never pulled. The Original format was - do { local $SIG{__WARN__} = sub { wa

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 Reasons?

On Feb 24, 2004, at 12:21 AM, WC -Sx- Jones wrote: There :) Now there aren't any errors: I believe/hope you are kidding here, but for the sake of those following along at home: There are no error messages printed in the following code because the eval() calls are assigned to a signal handler

Re: Eval Reasons?

On Feb 23, 2004, at 11:45 PM, WC -Sx- Jones wrote: Given - #!/usr/bin/perl -w # use strict; # use diagnostics; # 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 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 Reasons?

There :) Now there aren't any errors: #!/usr/bin/perl -w use strict; use warnings; my @strings = ( q('a poorly 'nested' string'), q('a poorly 'nested::test' string') ); do { local $SIG{__WARN__} = sub { foreach (@strings) { eval; print

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

Re: eval function

"Hmmm..." <[EMAIL PROTECTED]> wrote: > > In "Programming Perl", there is an example of eval in chapter 3 that I do > not understand. It is on page 161. It reads: > > Here's a statement that assigns an element to a hash chosen at run-time: > > eval "\$$arrayname{\$key} = 1"; > > I know the \ c

Re: eval parameters one liner

"John W. Krahn" wrote: > > > Try it like this: > > > > > > perl -le 'print eval "@ARGV"' > > > > Good on 'nix/'nux, I guess. On Windows, It takes a little different quoting: > > You mean like: > > perl -le "print eval [EMAIL PROTECTED]" > > > Greetings! E:\d_drive\perlStuff>perl -le "print eval $

Re: eval parameters one liner

"R. Joseph Newton" wrote: > > "John W. Krahn" wrote: > > > > Try it like this: > > > > perl -le 'print eval "@ARGV"' > > Good on 'nix/'nux, I guess. On Windows, It takes a little different quoting: You mean like: perl -le "print eval [EMAIL PROTECTED]" > Greetings! E:\d_drive\perlStuff>perl

Re: eval parameters one liner

"John W. Krahn" wrote: > Stephen Gilbert wrote: > > > > I know I saw something like this in the past I just can't find it. Anyone got any > > ideas? > > > > perl -e 'print eval { @ARGV }, "\n"' 5 + 5 > > > > it should be able to take any perl arithmetic operator. so: > > > > perl -e 'print eval {

Re: eval parameters one liner

On Mon, Sep 08, 2003 at 03:50:25PM -0400, Stephen Gilbert wrote: > I know I saw something like this in the past I just can't find it. Anyone got any > ideas? > > perl -e 'print eval { @ARGV }, "\n"' 5 + 5 > > it should be able to take any perl arithmetic operator. so: > > perl -e 'print eval {

Re: eval parameters one liner

Stephen Gilbert wrote: > > I know I saw something like this in the past I just can't find it. Anyone got any > ideas? > > perl -e 'print eval { @ARGV }, "\n"' 5 + 5 > > it should be able to take any perl arithmetic operator. so: > > perl -e 'print eval { @ARGV }, "\n"' 840928302840982 / 740983

Re: eval and __LINE__

> "Hacksaw" == Hacksaw <[EMAIL PROTECTED]> writes: Hacksaw> Okay, I'll bite. Why? Obviously it'd look bad, but your reaction seems Hacksaw> stronger than that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777

Re: eval and __LINE__

> Rob> use CGI::Carp 'fatalsToBrowser' > > Just remember NEVER to leave that on in production code. EVER. Okay, I'll bite. Why? Obviously it'd look bad, but your reaction seems stronger than that. -- The creative impulse animates whatever instrument is placed at its disposal. http://www.hack

Re: eval and __LINE__

> "Rob" == Rob Dixon <[EMAIL PROTECTED]> writes: Rob> use CGI::Carp 'fatalsToBrowser' Just remember NEVER to leave that on in production code. EVER. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/

Re: eval and __LINE__

> use CGI::Carp 'fatalsToBrowser' Ooo, cool. Thanks. Wow, two useful answers. I like this list. -- Commitments are to be honoured. http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED

Re: eval and __LINE__

Hacksaw wrote: > > I want to have something like die, but for the web, so I want it > to print out the error with a at the end, etc. > > How the F### do I get __LINE__ to be evaluated, not where it is in > the program file, but where the function is called? > > Another way of asking this is, how

Re: eval and __LINE__

>1) use Carp; - it shows errors from the caller's >perspective. Look at the docs, but you car use >'carp' (warinig) or 'croak' (die). >2) the perl built-in function 'caller' gives line and >script name information for the caller, the caller's >caller, etc. Check the docs to roll you

Re: eval and __LINE__

- Original Message - From: "Hacksaw" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, September 06, 2003 8:38 PM Subject: eval and __LINE__ > Caveat: It's late and I'm tired and frustrated, i.e. I'm pissy. > > I want to have something like die, but for the web, so I want it to

RE: Eval for module

> HI howdy again! > > I forgot to ask: > > Whenever I've tried to do: > > eval { use module; }; > if($@) . > > It always fails and I can't trap it it to , say, try a > different module if it's not found or otherwise do anythign, > (like tell a web browser user they need a certain

RE: Eval for module

> > That's because eval BLOCK still compiles the block at > compile-time. You want to use eval EXPR. > > eval 'use Module ...; 1'; > if ($@) { uh oh } > > You can also use q{} instead of single quotes for more > code-like appearance. Excellent Jeff! Thanks for that tid bit I missed it so

Re: Eval for module

On Aug 6, Dan Muey said: >Whenever I've tried to do: > > eval { use module; }; > if($@) . > >It always fails and I can't trap it it to , say, try a different module >if it's not found or otherwise do anythign, (like tell a web browser user >they need a certain module for it to work: Tha

RE: eval and alarm timeout for slow process (XML post)

> -Original Message- > From: jeff loetel [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 22, 2002 9:01 AM > To: Perl beginners > Subject: eval and alarm timeout for slow process (XML post) > > > Does this look correct below. I know that I should test but > due to the environment tha

RE: eval help needed.

Well what I want to do is backup my Eudora mailboxes, and I have that part working, but I wanna automate it so that every time I close Eudora the files get copied. A suggestion was that I could wrap the call to Eudora in an eval and just call Eudora from the Perl Script. At 07:23 PM 11/18/02

RE: eval help needed.

I've never played with it, but I think what you need is the perl win32 OLE libaray...basically, it gives you VBScript-like access to win32 objects and applications via perl! check it out: http://aspn.activestate.com/ASPN/Perl/Products/ActivePerl/site/lib/Win32/OLE ..html I'm not sure what you're

Re: eval on a $SIG{KILL}- newbie question

I think Bob's theory 1 fits. The die is never called. You put an alarm handler into your program which is set for 10 seconds. I suppose the timeout for the ssh module is more like 30 seconds, so the alarm catches first. On Tue, Aug 27, 2002 at 01:46:20PM -0400, Chad Kellerman wrote: > > How do

Re: eval on a $SIG{KILL}- newbie question

Chad Kellerman wrote: > Sorry everybody, > >I have been trying to work on this all day but nothing... > > IF a perl module uses: > connect($sock, sockaddr_in($rport, $raddr)) > or die "Can't connect to $ssh->{host}, port $rport: $!"; > > How do I catch the die() in an eval statemen

RE: eval on a $SIG{KILL}- newbie question

> -Original Message- > From: Chad Kellerman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 27, 2002 1:46 PM > To: [EMAIL PROTECTED] > Subject: Re: eval on a $SIG{KILL}- newbie question > > > Sorry everybody, > >I have been trying to work on this al

Re: eval on a $SIG{KILL}- newbie question

ote: > > -Original Message- > > From: Chad Kellerman [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, August 27, 2002 8:58 AM > > To: [EMAIL PROTECTED] > > Subject: Re: eval on a $SIG{KILL}- newbie question > > > > > > Bob, > > Thanks f

RE: eval on a $SIG{KILL}- newbie question

> -Original Message- > From: Chad Kellerman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 27, 2002 8:58 AM > To: [EMAIL PROTECTED] > Subject: Re: eval on a $SIG{KILL}- newbie question > > > Bob, > Thanks for the responce. I did not realize y

  1   2   >