in reply to #include files

If you're not adverse to some simple source filtering then Filter::Include is the module for you. However, if you are adverse to source filtering there's always the C preprocessor flag -P which will work in a similar fashion (see. perlrun for more info).

And the reason you can't see my variables from the included script is because my declares a lexical variable which will falls out of scope at the end of a file (as lexical variables are declared into the surrounding file scope by default). So your alternatives are to either export your variables by implementing import() and turning your file into a module (perhaps not ideal for your situation), or using package variables which are visible throughout the execution of a program.

HTH

_________
broquaint

Replies are listed 'Best First'.
Re: Re: #include files
by Anonymous Monk on Oct 26, 2003 at 17:48 UTC
    Filter::Include was the solution, thank you for that advice (and for your authorship). My intention was to write tests for a module. The test routines directly use not explicitly exported symbols in the module. I split the module and the tests in separate files, so I had to fully qualify the not explicitly exported symbols - very uncomfortable and not adequate for a module that knows so much about the the other. A workaround was "BEGIN { `cat x-module x-test>x`}; use x", but that was very ugly. "use Filter::Include; include "x-test" is much nicer. But there keeps one problem: Line numbering isn't considered; the including file and the included file are handled as one big file, so line numbers after the first inclusion are wrong. Bye, jds00.
[reply]
      Thanks for the heads up on line numbering. As of version 1.4 that should be corrected thanks to the #line directive (although you'll also need Module::Locate, but it's dependencies are few and common).
      HTH

      _________
      broquaint

[reply]

In Section Seekers of Perl Wisdom