Using perl -d scriptname will take you into the debugger and then there are the X and Y cammands that will display all the vars know in the current program (or package) at the current point in the program.
This means that if all your varables are globals (a BAD idea) then with the exception of any created through eval's, autovivification and the like, you would be able to see all your vars immediatly the debugger has loaded.
However, if you are being good and using my and or our vars, then these do not come into existance (visibility?) until the line where the are declared (my'd or our'd) has been executed. Which means you need set a break point and run to it & then use the X or Y commands to see what variables are visible at that point in the code.
I don't know of anything better than this.
I might think about trying to write a source file parser to extract variable names and line numbers, but I've seen the quote "Only Perl can parse perl" often enough to dismiss that idea:)
One trick that might give you most of the information if your code doesn't use globals is to use your editor or another perl script or one-liner:) to globally replace the word "my" with something easily identifiable (I used 1;;;;;;;;;) that will be easy to revert. Leave strict enabled and try and run the program. You get output that looks like
C:\test>calc
Global symbol "$tree" requires explicit package name at C:\test\calc.p
+l line 8.
Global symbol "$tree" requires explicit package name at C:\test\calc.p
+l line 9.
....
Global symbol "@ops" requires explicit package name at C:\test\calc.pl
+ line 77.
Global symbol "@ops" requires explicit package name at C:\test\calc.pl
+ line 78.
Execution of C:\test\calc.pl aborted due to compilation errors.
C:\test>
Combining this information with the dump of globals from the debugger should cover most things.
Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring! |