RFR: 8289646: configure script failed on WSL

[Yasumasa Suenaga]

On Mon, 4 Jul 2022 16:26:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> configure failed as following when I run it on WSL 1.
>> 
>> 
>> checking for version string... 20-internal-adhoc.yasuenag.jdk
>> configure: Found potential Boot JDK using configure arguments
>> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found.
>> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java
>> configure exiting with result code 1
>> 
>> 
>> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least).
>> 
>> WSL v0.60.0.0
>> 
>> $ wslpath -w silver-bullet
>> wslpath: silver-bullet: No such file or directory
>> $ echo $?
>> 1
>> 
>> 
>> WSL v0.61.4.0
>> 
>> $ wslpath -w silver-bullet
>> silver-bullet
>> $ echo $?
>> 0
>> 
>> 
>> We should add ".exe" at the tail of path regardless of return value from wslpath.
>
> I added some comments. As a minimum, you need to verify that this works on WSL1, WSL2 and Cygwin. Ideally, you would test on msys2 as well. You will need to verify that importing paths works for executables both with and without .exe, both if they reside in the winenv root (like in /tmp) or on the Windows drive (like /cygwin/d/data/...).
> 
> As I wrote, I think you might run into problems for things like /tmp/foo.exe on WSL1. It might also work on newer versions of wslpath but break on older, seeing that Microsoft is in the habit of changing the behaviour of wslpath...

Thanks @magicus for your comment!
I thought we can remove `unixpath` to simplify fixpath in this patch, but we can use it to keep current behavior. So I updated this PR to use `unixpath`. Could you review again? It uses `test -e` instead of return code from wslpath.

-------------

PR: https://git.openjdk.org/jdk/pull/9357