I am converting one of my platform applications to be accessible from the command line and I have found that relative file paths specified on the command line are always misinterpreted on Microsoft Windows (at least on Windows XP). It appears to work correctly on the various forms of UNIX I've tried.
I will attach a suite which demonstrates this problem. Here is what I found/expected when running the program:
1. I built the suite as a ZIP distribution.
2. I unpacked the ZIP to c:\testing\wrongcwdsuite
3. I opened a command prompt and typed "cd C:\temp" to set this as my current directory.
4. I typed the following command (there was a text file 'myfile.txt' in the current directory of c:\temp):
\testing\wrongcwdsuite\bin\wrongcwdsuite.exe --nogui --nosplash --testcwd myfile.txt
5. Since I executed the command from the C:\temp directory, I would have expected that would have been my working directory and relative file paths would be relative to there. However, this is the output I found:
CWD from 'env' instance: C:\testing\wrongcwdsuite
user.dir system property: C:\testing\wrongcwdsuite
File path using single-arg ctor: C:\testing\wrongcwdsuite\myfile.txt
- does this file exist?: false
File path using two-arg ctor: C:\testing\wrongcwdsuite\myfile.txt
- does this file exist?: false
Created attachment 101617 [details]
Suite which illustrates the problem
Just changing CWD is going to incompatible for example for bug 168465.
Created attachment 101698 [details]
Recompiled app.exe. Tom please verify that it works for you
Created attachment 101699 [details]
The trivial, but incompatible fix
I will need to come up with some more compatible fix. For example I could also modify app.conf to contain some information or command line option whether the current directory shall remain where it is or be moved to basedir.
Thanks for looking at this. I have confirmed that the attached app.exe yields the desired behavior.
I also understand that some applications may depend on the current behavior of Env.getCurrentDirectory() and changing it would be compatible. Based on this, it would be totally acceptable to leave the current behavior and add a new method (perhaps Env.getExecutionDirectory()) which provides access to the directory from which the command was invoked, plus a tiny bit of Javadoc which explains how these two methods differ on Windows system. If you don't want to add a new method to Env, maybe the launcher could set a Java system property that points to this location.
Your proposed solution is also fine. My goal is simply to resolve relative file paths based on the directory from which the command was invoked. Really, pretty much any solution which allows that -- even if I need to write a little extra code -- is OK with me.
Instead of "changing it would be compatible" I meant "changing it would be INcompatible". I am off to get some more coffee now...
Integrated into 'main-golden', will be available in build *201009010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <firstname.lastname@example.org>
Log: #189791: Pass current directory in netbeans.user.dir property
Verified using current main-golden build.
Thanks so much for the fix!