NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in <199911192358.PAA24109@kiev.wall.org>
Did I say I expect Perl to do the right thing? :-)
--Larry Wall in <199911200217.SAA24898@kiev.wall.org>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
exec (Score:1)
Runtime.exec(String[] cmdarray, String[] envp, File dir) [sun.com] does envvars and working dirs for forked processes. Which is a little bit toward what you want...
A major problem with envvars and working dirs as implemented in Perl, for example, is that they are process global. That wreaks havoc on the extreme isolation that Java strives for. So, I would argue that give Java's goals, the lack of %ENV and setcwd() is a feature.
But the lack of copy? That's a real nuisance.
Reply to This
Re: (Score:2)
Yeah, I can set it for subprocesses, and I am. But I want to just set it for my current process so the subprocesses can inherit it. Also I am calling an ant build that unfortunately depends on environment variables (for the moment -- hopefully to be corrected next year, but there's no time right now), and since there is no way to set them, I had to rip out all of the nice code I had for calling that in my current process and pleasantly reading and organizing its output, and replace it with code to call it
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re: (Score:1)
A hack: when you first start the build, re-invoke ant via the java [apache.org] task with the proper envvars. Then all subsequent execs get that env.
$work does a similar re-invoke to ensure that the build is running with the proper JDK and Ant (bundled with the code) to guarantee that all developers build with the selected JRE for each project.
Re: (Score:1)
Once again bearing out the waterbed theory of complexity…