in reply to (tye)Re: Debugger, use strict, use warnings
in thread Debugger, use strict, use warnings

Coleoid wrote:
Now, I know (through experimentation) that if I do: perl -wde 0 ...I've got the warnings.

tye wrote:
Then you didn't do enough experimenting. ;)

> perl -we "print 0+'abc'" Argument "abc" isn't numeric in addition (+) at -e line 1. 0 > perl -wde 0 DB<1> print 0+'abc' 0

Hmm. My experiments were assorted hijinks with undef:

>perl -wde 0 DB<1> print undef; Use of uninitialized value in print at (eval 5) [D:/Perl/lib/perl5db.p +l:1510] line 2, <IN> line 1.
So this gives me another question: Why which where? Some warnings, some of the time?

And here I thought I almost got it. Time to hit the docs again.

Replies are listed 'Best First'.
(tye)Re4: Debugger, use strict, use warnings
by tye (Sage) on Apr 11, 2001 at 20:54 UTC

    As I already said "you can get run-time warnings but not compile-time warnings for code entered at the debuger's command prompt," which I think answers part of your question. And I doubt there are any docs that cover this.

    As for the "why", I assume that the debugger restores $^W in-line with the eval of your code via the equivalent of eval "\$^W= $saved; $your_code" (it actually restores quite a few things so the syntax isn't quite what I wrote) which means that $^W isn't restored until after that code is compiled. Patching the debugger to do eval "BEGIN{$^W= saved} $your_code" would correct that but you'll have to be careful to separate the things that need to be restored at compile time from the things that can't be restored from within the BEGIN block because the restoration would be ruined when you leave the scope of that block.

    Creating such a patch sounds like a reasonable project. Let me know if you run into problems. ;)

            - tye (but my friends call me "Tye")