in reply to Debugger, use strict, use warnings

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

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

[download]
But then your example surprised me because I had assumed that the debugger never gave me warnings for code entered at the command prompt.

So I experimented further and decided that you can get run-time warnings but not compile-time warnings for code entered at the debuger's command prompt.

But back to your real question...

The debuger runs your code using eval (how else?). So your example code ends up being closer to this: 

eval "use strict;";
eval "use warnings;";
eval "print undef;";
eval 'print $x[undef];';

[download]
and pragmas obey scope so it makes sense (to me, at least) that use warnings and use strict don't do much good in the above code.

I was going to suggest that you make a file e.pm: 

use strict;
use warnings;
1

[download]
so you could do: 
perl -de 0
  DB<1> use e; print $x[undef]

[download]
but that doesn't do any good.

But that reminds me! How do you make pragma magic creep up an extra level of scope? I know how to do this with modules that export symbols. Sometimes it'd be nice to do that with pragmas as well.

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

Replies are listed 'Best First'.
Re (tilly) 2: Debugger, use strict, use warnings
by tilly (Archbishop) on Apr 10, 2001 at 20:52 UTC
    Making pragma logic move up an extra level of scope is easiest done by using caller to get your caller's package name and then doing an eval which sets the package and then calls the pragma.

    There are various compilation/runtime timing issues you have to get straight of course. But that will work.

[reply]

      I'd like to see an example. I believe that pragmas affect the scope that is one level up not on the package that is one level up so I don't see how your suggestion would do any good.

              - tye (but my friends call me "Tye")
[reply]
        My bad. I was thinking of vars. For pragmas you have to be a little creative. But if you use what I learned at Re (tilly) 1: How does strict work?, it is doable but slightly tricky.

        Perhaps an example would be best.

        Suppose that you wanted a version of strict and vars wrapped up in one, takes one argument list and splits it in the obvious way between strict and vars... 

        package my_strict;
use strict;
use vars;

sub import {
  shift; # I know my class name I hope
  my (@vars, @strictures);
  foreach (@_) {
    if (/\W/) {
      push @vars, $_;
    }
    else {
      push @strictures, $_;
    }
  }
  
  my $pkg = caller;
  $^H = eval "
    package $pkg;
    no strict;
    use strict qw(@strictures);
    vars->import(\@vars);
    \$^H;
  ";
}

1;

        [download]
        Is that what you wanted?
[reply]
[d/l]
Re: (tye) Debugger, use strict, use warnings
by Coleoid (Sexton) on Apr 11, 2001 at 20:26 UTC
    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

    [download]

    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.

    [download]
    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.

[reply]
[d/l]
[select]

      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")
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom