On 28 Jul 2004 at 15:34, Glenn Linderman wrote: > Yeah, I suppose. Too many options, eh?
PAR could go nuts trying to accommodate everything Perl can do. As they say, "only perl can parse Perl". > But wouldn't that also be > problematical for PAR scripts with different versions of the same > modules, both run under PAR_TEMP? So shouldn't "inc" be renamed to > inc-gibberish, to avoid such problems? > Probably so. The modules that are auto loaded by use/require come from the temp dir and have different names. The modules in inc/ are there for modules that need to parse lib source themselves. But that could be a conflict if using multiple versions of such source-munging modules. The other problem with inc/ is that it is not even created if "pp -C", so scripts with such modules can't auto clean up after themselves. > > They are not removed. Again it's difficult to do all things. If all the PAR %ENV > > values > > are provided to your script, it's your script that launches the next script, so > > PAR has > > no way of removing environment variables prior to the launch. > > OK, but my PAR enabled script could undef all %ENV entries that start > match PAR_.* and resolve this issue? > Sure. Alan Stewart
