subtle bug in Java version discovery, the `java.exe` in the `for` statement should be changed to `.\java.exe`

[marcmcd]

In scripts\StartIBC.bat, there's the line

for /f "tokens=1,2 delims== usebackq" %%A in (`java.exe -XshowSettings:properties 2^>^&1 ^| findstr /C:"java.version ="`) do set java_version=%%B

the java.exe in the for statement should be changed to .\java.exe because just java.exe can cause the warning:

'java.exe' is not recognized as an internal or external command,
operable program or batch file.

this causes the variable java_version to never be set, and the later line

if not "%java_version:1.8=%"=="%java_version%" set moduleAccess=

then crashes the script with the error set was unexpected at this time, neatly escalating a warning into a crash, and
needless to say, the IB TWS or Gateway, which are called later, never run.

This 'java.exe' is not recognized issue can happen if the cmd or Powershell environment that runs StartIBC.bat is not set up correctly.
Using just java.exe can work if your terminal's PATH includes . or has other settings that allow current-directory search,
or your terminal has system-wide PATH that includes common directories. If this is not the case, then it may not work, which has definitely happened on my Windows 10 box and the fix below worked.

The fix is to change the java.exe in

:: temporarily change the current working directory because using "%JAVA_PATH%\java.exe" in the following 'for' statement causes an error
pushd "%JAVA_PATH%"
for /f "tokens=1,2 delims== usebackq" %%A in (`java.exe -XshowSettings:properties 2^>^&1 ^| findstr /C:"java.version ="`) do set java_version=%%B
:: restore the original current working directory
popd

to .\java.exe as follows

:: temporarily change the current working directory because using "%JAVA_PATH%\java.exe" in the following 'for' statement causes an error
pushd "%JAVA_PATH%"
for /f "tokens=1,2 delims== usebackq" %%A in (`.\java.exe -XshowSettings:properties 2^>^&1 ^| findstr /C:"java.version ="`) do set java_version=%%B
:: restore the original current working directory
popd

[rlktradewright]

I'm not convinced that there is any issue here.

When loading an executable, Windows always searches the current working directory for it first. Only if it doesn't find it there will it search the PATH folders.

But the script sets the current working directory to %JAVA_PATH% immediately before invoking java.exe, and the presence of java.exe in that path has already been verified when setting the JAVA_PATH variable. So I don't see how the java.exe can fail to be found.

So if you want to convince me that this amendment is needed, please provide a concrete example that makes this happen.

[marcmcd]

Thanks for responding so quickly.
The use case where I encountered this issue was in a python program which uses the ib_async library to launch the IBC in the file
.venv\Lib\site-packages\ib_async\ibcontroller.py :

        # run shell command
        self._proc = await asyncio.create_subprocess_exec(
            *cmd, stdout=asyncio.subprocess.PIPE
        )

where I've determined that the cmd array contains

 cmd: ['C:\\\\IBC\\\\scripts\\\\StartIBC.bat', '1045', '/Gateway', '/Mode:paper', '/TwsPath:C:\\\\Jts', '/IbcPath:C:\\\\IBC', '/Config:C:\\\\IBC\\\\config.ini', '/User:XXXXXX', '/PW:XXXXXXX']", "module": "ibcontroller", "line": 165}

When I ran the python manually program from a Powershell 7 terminal , the IB Gateway window would open.
When I asked Claude Code to run the same Python program in the same command, this issue was encountered
and the IB Gateway would not open.

After digging into the issue for a day, I finally found the issue, but I still have no idea why
when Claude Code runs the command, java.exe is suddenly not found even though the pushd command
does work and the current folder does contain a java.exe . But .\java.exe is always found.

However maybe this is an issue for the ib_async repo instead because they should
use await asyncio.create_subprocess_shell() instead of await asyncio.create_subprocess_exec().

Maybe this is an edge case that will only be encountered by me, and I understand your reluctance
to change the IBC code due to possible regression issues, so you can close this issue.
It is sufficient for me that the developers are aware of this issue.

[marcmcd]

I found the exact reason for the issue. When running commands in a shell, Claude code sets then cmd env var NODEFAULTCURRENTDIRECTORYINEXEPATH=1 as a security measure and
"NODEFAULTCURRENTDIRECTORYINEXEPATH=1 is a Windows environment variable setting used to improve security by preventing the operating system from searching the Current Working Directory (CWD) for executables."

[marcmcd]

Since changing java.exe in the for statement to .\java.exe makes the script
vulnerable to a malicious attack, I no longer recommend doing that.
To stop the line

if not "%java_version:1.8=%"=="%java_version%" set moduleAccess=

from crashing the script because the variable java_version is not set, I just replace
it with the delayed expansion version:

if not "!java_version:1.8=!"=="!java_version!" set moduleAccess=

When Claude Code runs the python program that uses ib_sync to call StartIBC.bat,
java_version version is never set because NODEFAULTCURRENTDIRECTORYINEXEPATH=1,
StartIBC.bat will execute the set moduleAccess= statement (which is desired since I'm using
Java 17 and not 1.8=8) and start the IB Gateway correctly.