Installing BSF3ooRexx on W11 does not update the class path environment variables. It is still possible to manually edit them, or to run a script that sets them.
BSF4ooRexx install/environment status — summary for Rony and the ticket
System: Windows 10.0.26200.8875. OpenJDK 21.0.5.11 (IBM Semeru, Eclipse OpenJ9), confirmed same bitness as ooRexx (both 64-bit).
Install, in order actually run
Downloaded the BSF4ooRexx installer zip, unpacked to a staging folder under Downloads.
First attempt: ran install.cmd by full path from C:\Users\Owner (i.e. not the install directory) — failed immediately: Error 3.901: Failure during initialization: Program "kickoff.rex" was not found. This looks like a relative-path lookup inside install.cmd that assumes the current directory is the install folder.
Second attempt: cd'd into ...\bsf4oorexx\install\windows\, then ran install from there. Printed Starting installation ... and completed — confirmed after the fact via a full directory listing: C:\Program Files\BSF4ooRexx850\ is fully populated (DLL, the BSF4ooRexx JAR, samples, .reg files for REX/RXJ/RXO associations, setEnvironment4BSF.cmd, setEnvironment4OOo.cmd, install/uninstall scripts, etc.) with timestamps matching this run.
Open question, not confirmed either way: whether real UAC elevation actually happened during step 3. elevate.rex uses .OLEObject~New("Shell.Application") (WSH/COM automation) to trigger the UAC prompt, and kickoff.rex's own docstring documents a silent fallback to running without elevation if that fails. No UAC prompt was explicitly noted in the transcript, so it's unclear whether elevation succeeded or the non-elevated fallback silently took over — which would explain why the files installed correctly but persistent system-wide environment variables may never have been set.
The persisting symptom
A plain rexx script containing ::REQUIRES "BSF.CLS" fails to find BSF.CLS when run from a freshly-opened terminal, even after the install above completed. Confirmed along the way:
BSF.CLS itself exists at C:\Program Files\BSF4ooRexx850\BSF.CLS.
PATH (checked via echo %path%) does include C:\Program Files\BSF4ooRexx850.
BSF4OOREXX_HOME is not set as a persistent environment variable (echo %BSF4OOREXX_HOME% prints the literal unexpanded text).
setEnvironment4BSF.cmd exists at C:\Program Files\BSF4ooRexx850\install\setEnvironment4BSF.cmd — confirms setupBSF.rex ran successfully during install.
Separately found: a real bug in rexxj.cmd
rexxj.cmd's internal for /F loop against %BSF4OOREXX_HOME%\lib breaks because BSF4OOREXX_HOME resolves to a path containing a space (C:\Program Files...) and isn't quoted inside that loop. Reproduced directly:
dir /B C:\Program Files\BSF4ooRexx850\lib (unquoted) → The system cannot find the path specified.
dir /B "C:\Program Files\BSF4ooRexx850\lib" (quoted) → works, lists the jars correctly.
This is independent of the environment-variable question above, but worth reporting since it'll hit anyone who installs to the default (space-containing) location.
Latest test, needs manual re-verification
Per your guidance that the environment setup is per-terminal-session by design, I tried sourcing setEnvironment4BSF.cmd then running rexx on a small probe script (::requires "BSF.CLS" + instantiate java.lang.String) via an automated harness:
The harness reported rc=-99 with no captured stdout or stderr at all. Given that zero-output pattern showed up once before with a genuinely malformed command (harness bug, not a real failure), I don't trust this result as a description of what the command actually does — it needs to be run directly in an interactive window to get a trustworthy answer, which I haven't done yet.
Answering your direct question
"Does the test work with a different CWD?" — not yet tested. Will report back.
What I'll do next
Run the exact command above directly in an interactive terminal (not through the automation) and report the real output, plus test from a different CWD as you asked.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to the readme, before unzipping, you should unblock the zip archive, either via the zip file's property pop-up (mark unblock, then press apply), or use "powershell unblock-file *"
Did you unblock before unzipping? If not, it would explain why the installation does not work, as Windows itself will inhibit the execution/usage of blocked programs and DLLs.
The readme states to either change into bsf4oorexx\install\windows and run the script manually from there, or to double-click via the Explorer, which should run the script in its directory as the current directory. Both paths should successfully run the installer, which, as you write, works relative to the current directory.
If you have traces of prior installations that did not work, do the following: remove the directory "rd %ProgramFiles%\BSF4ooRexx850 /s" before attempting a new installation.
One thing that might be helpful. The installation will create a log file in your home directory named "BSF4ooRexx850_2026-mm-ddTHH-MM-SS.mseclog". Please upload it to the bug report.
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BSF4ooRexx install/environment status — summary for Rony and the ticket
System: Windows 10.0.26200.8875. OpenJDK 21.0.5.11 (IBM Semeru, Eclipse OpenJ9), confirmed same bitness as ooRexx (both 64-bit).
Install, in order actually run
Downloaded the BSF4ooRexx installer zip, unpacked to a staging folder under Downloads.
First attempt: ran install.cmd by full path from C:\Users\Owner (i.e. not the install directory) — failed immediately: Error 3.901: Failure during initialization: Program "kickoff.rex" was not found. This looks like a relative-path lookup inside install.cmd that assumes the current directory is the install folder.
Second attempt: cd'd into ...\bsf4oorexx\install\windows\, then ran install from there. Printed Starting installation ... and completed — confirmed after the fact via a full directory listing: C:\Program Files\BSF4ooRexx850\ is fully populated (DLL, the BSF4ooRexx JAR, samples, .reg files for REX/RXJ/RXO associations, setEnvironment4BSF.cmd, setEnvironment4OOo.cmd, install/uninstall scripts, etc.) with timestamps matching this run.
Open question, not confirmed either way: whether real UAC elevation actually happened during step 3. elevate.rex uses .OLEObject~New("Shell.Application") (WSH/COM automation) to trigger the UAC prompt, and kickoff.rex's own docstring documents a silent fallback to running without elevation if that fails. No UAC prompt was explicitly noted in the transcript, so it's unclear whether elevation succeeded or the non-elevated fallback silently took over — which would explain why the files installed correctly but persistent system-wide environment variables may never have been set.
The persisting symptom
A plain rexx script containing ::REQUIRES "BSF.CLS" fails to find BSF.CLS when run from a freshly-opened terminal, even after the install above completed. Confirmed along the way:
BSF.CLS itself exists at C:\Program Files\BSF4ooRexx850\BSF.CLS.
PATH (checked via echo %path%) does include C:\Program Files\BSF4ooRexx850.
BSF4OOREXX_HOME is not set as a persistent environment variable (echo %BSF4OOREXX_HOME% prints the literal unexpanded text).
setEnvironment4BSF.cmd exists at C:\Program Files\BSF4ooRexx850\install\setEnvironment4BSF.cmd — confirms setupBSF.rex ran successfully during install.
Separately found: a real bug in rexxj.cmd
rexxj.cmd's internal for /F loop against %BSF4OOREXX_HOME%\lib breaks because BSF4OOREXX_HOME resolves to a path containing a space (C:\Program Files...) and isn't quoted inside that loop. Reproduced directly:
dir /B C:\Program Files\BSF4ooRexx850\lib (unquoted) → The system cannot find the path specified.
dir /B "C:\Program Files\BSF4ooRexx850\lib" (quoted) → works, lists the jars correctly.
This is independent of the environment-variable question above, but worth reporting since it'll hit anyone who installs to the default (space-containing) location.
Latest test, needs manual re-verification
Per your guidance that the environment setup is per-terminal-session by design, I tried sourcing setEnvironment4BSF.cmd then running rexx on a small probe script (::requires "BSF.CLS" + instantiate java.lang.String) via an automated harness:
call "C:\Program Files\BSF4ooRexx850\install\setEnvironment4BSF.cmd" && rexx "<probe>.rex"</probe>
The harness reported rc=-99 with no captured stdout or stderr at all. Given that zero-output pattern showed up once before with a genuinely malformed command (harness bug, not a real failure), I don't trust this result as a description of what the command actually does — it needs to be run directly in an interactive window to get a trustworthy answer, which I haven't done yet.
Answering your direct question
"Does the test work with a different CWD?" — not yet tested. Will report back.
What I'll do next
Run the exact command above directly in an interactive terminal (not through the automation) and report the real output, plus test from a different CWD as you asked.
Thank you, Shmuel!
According to the readme, before unzipping, you should unblock the zip archive, either via the zip file's property pop-up (mark unblock, then press apply), or use "powershell unblock-file *"
Did you unblock before unzipping? If not, it would explain why the installation does not work, as Windows itself will inhibit the execution/usage of blocked programs and DLLs.
The readme states to either change into bsf4oorexx\install\windows and run the script manually from there, or to double-click via the Explorer, which should run the script in its directory as the current directory. Both paths should successfully run the installer, which, as you write, works relative to the current directory.
If you have traces of prior installations that did not work, do the following: remove the directory "rd %ProgramFiles%\BSF4ooRexx850 /s" before attempting a new installation.
One thing that might be helpful. The installation will create a log file in your home directory named "BSF4ooRexx850_2026-mm-ddTHH-MM-SS.mseclog". Please upload it to the bug report.
Thank you.
That sound like the issue; I'll try it. Thanks.