Chris Woods writes:
> Paul Kinnucan wrote:
>
>
> > I've already tried this and it does not work. Specifically, I tried the
> > equivalent of:
> >
> > cd c:/foo
> > javac Bar.java
>
>
> Here's a transcript of what I've managed:
>
> bsh % cd("/home/cwoods/code/java/jdbc");
> bsh % addClassPath(".");
> bsh % addClassPath("/usr/local/java");
> bsh % addClassPath("/usr/local/cloudscape/lib/cloudscape.jar");
> bsh % addClassPath("/usr/local/cloudscape/lib/tools.jar");
> bsh % addClassPath("/usr/local/cloudscape/lib/client.jar");
> bsh % exec("javac -d /usr/local/java InsertRows.java");
> bsh%
>
> I started the interpreter in /home/cwoods. Successfully did the cd()
> operation as above. The "InsertRows.java" file exists in
> "/home/cwoods/code/java/jdbc". I checked to be sure, and the
> exec("javac...") command did successfully compile the code.
>
I think this is because the Beanshell is passing its notion of the cwd to the
Runtime.exec method, which allows starting a process with a specified working
directory.
> Again, this is from the Beanshell interpreter prompt; I haven't tried
> calling the functionality programatically.
>
> For obvious reasons, calling exec("some-native-process") is not very
> clean, but being able to call javac is not the intent of the experiment.
> It is called merely to verify that the cd() command actually worked.
>
I don't think it worked in the sense of changing the working directory
of the Beanshell vm, which is critical to what I want to do.
> It strikes me that setting the user.dir property is not very clean
> either, but it's just a personal quirk that I generally don't like to
> write to any of the standard System properties.
I've verified that changing user.dir does NOT change the working directory
of the Beanshell process.
- Paul
