Scoop install: published wheels.cmd hits two Windows-only bugs (JAVA_HOME path + cmd.exe parses lucli bat-jar tail)

[bpamiri]

The Scoop-installed wheels CLI is broken on at least some Windows configurations. Two distinct bugs compound.

Bug 1 — JAVA_HOME points at a non-existent path

The published wheels.cmd (under ~/scoop/apps/wheels/current/wheels.cmd) sets:

set "JAVA_HOME=%~dp0share\jdk"
set "PATH=%JAVA_HOME%\bin;%PATH%"

On a scoop install, share/ contains only module/ and framework/ — there is no share/jdk/. The brew formula (tools/distribution-drafts/homebrew/wheels-be.rb:93) sets JAVA_HOME to Formula["openjdk@21"].opt_prefix, which is a real path; the Windows wrapper was written assuming a parallel share\jdk layout that scoop never produces.

The current tools/distribution-drafts/scoop/build-manifests.py already drops these two lines, so the source-of-truth is clean — but the published wheels-dev/scoop-wheels bucket manifest is stale and existing installs still carry the broken wrapper.

Bug 2 — call "%~dp0lucli-0.3.7.bat" chokes cmd.exe on the JAR tail

lucli-0.3.7.bat is a ~915 KB bat-jar concatenation (small bat preamble that runs java -jar "%~f0", followed by :JAR_BOUNDARY and the raw JAR ZIP bytes). When wheels.cmd does:

call "%~dp0lucli-0.3.7.bat" %*

cmd.exe pre-parses the entire bat file looking for labels/control flow. On this Windows build (Win 11 Pro 10.0.26200.8457), that pre-parse trips on a byte sequence in the JAR tail and aborts with:

The filename, directory name, or volume label syntax is incorrect.

…before lucli-0.3.7.bat ever executes. Reproduction:

cmd /c 'C:\Users\peter\scoop\apps\wheels\current\lucli-0.3.7.bat --help'
# -> ERROR_INVALID_NAME (0x7B), exit 1

Bypassing the bat-jar self-execution by invoking Java directly works:

"%JAVA_HOME%\bin\java.exe" -client -jar "%~dp0lucli-0.3.7.bat" %*

Proposed fix (in build-manifests.py::cmd_wrapper)

Replace the call "%~dp0lucli-<ver>.bat" %* line with a direct Java invocation that doesn't make cmd.exe parse the bat-jar:

f'"%JAVA_HOME%\\bin\\java.exe" -client -jar "%~dp0lucli-{LUCLI_VERSION}.bat" %*',

…and add a JAVA_HOME resolver near the top of the wrapper that finds the scoop openjdk21\current dir (the dependency declared by "depends": "java/openjdk21"), so users without a system Java still work.

Repro environment

• OS: Windows 11 Pro 10.0.26200.8457
• Wheels: 4.0.0-SNAPSHOT+1442 (stable channel via scoop)
• LuCLI bat sha512 matches the manifest pin (75c948...dd71b), so this is not a corrupted download.
• Bundled jdk-21.0.2/ exists under the wheels app dir on this install (curious — depends: java/openjdk21 should have put it in a sibling scoop app, not here; may indicate this install came from an older manifest).

Workaround for affected users

Edit ~/scoop/apps/wheels/current/wheels.cmd:

1. Change set "JAVA_HOME=%~dp0share\jdk" -> set "JAVA_HOME=%~dp0jdk-21.0.2" (or point at your actual scoop openjdk21\current path).
2. Change call "%~dp0lucli-0.3.7.bat" %* -> "%JAVA_HOME%\bin\java.exe" -client -jar "%~dp0lucli-0.3.7.bat" %*.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

Suspected layer

cli — the issue concerns the Scoop installer's wheels.cmd wrapper. The source of truth is tools/distribution-drafts/scoop/build-manifests.py (see cmd_wrapper() at line 43, with the affected call "%~dp0lucli-<ver>.bat" %* line at 99). See CLAUDE.md § "CLI / MCP" for CLI conventions.

Fix sketch

Two changes in tools/distribution-drafts/scoop/build-manifests.py::cmd_wrapper:

1. Replace call "%~dp0lucli-{LUCLI_VERSION}.bat" %* with a direct Java invocation: "%JAVA_HOME%\bin\java.exe" -client -jar "%~dp0lucli-{LUCLI_VERSION}.bat" %* — bypasses cmd.exe's bat-file pre-parser that chokes on the JAR ZIP tail bytes.
2. Add a JAVA_HOME resolver near the top of the wrapper that locates the Scoop openjdk21\current dir (declared via "depends": "java/openjdk21" in the manifest), since the previous %~dp0share\jdk path doesn't exist in a Scoop layout.

After regenerating manifests, the wheels-dev/scoop-wheels bucket needs republishing so existing installs pick up the fix on their next scoop update.

Confidence: `high`

The reporter provided a clear repro on Windows 11, isolated both failure modes to specific bytes/paths, and identified the exact file and lines to change. The fix is mechanical, scoped to one Python script under tools/distribution-drafts/, and doesn't touch security, middleware, migrations, the wheels deploy (Kamal) subsystem, DI, or cross-engine CFML code paths.

<!-- wheels-bot:triage:2765 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:high -->

[wheels-bot]

Wheels Bot — Fix proposed

Draft PR: #2766

Spec: vendor/wheels/tests/specs/cli/ScoopWrapperSpec.cfc — failing → passing (9 specs, 2 pass + 7 fail at baseline; 9 pass + 0 fail after fix)
Implementation: tools/distribution-drafts/scoop/build-manifests.py, tools/distribution-drafts/scoop/wheels-be.json, tools/distribution-drafts/scoop/wheels.json

A human review is required before merge. Reviewer A and Reviewer B will weigh in shortly. Doc updates (MDX guides, .ai/wheels/, CLAUDE.md) are handled separately by bot-update-docs.yml.

The published wheels-dev/scoop-wheels bucket needs republishing for existing Windows installs to pick up the fix on their next scoop update.

[bpamiri]

Cross-reference: the actionable fix lives in the bucket repo, not here. The tools/distribution-drafts/scoop/ files are draft references; what scoop install wheels actually reads is wheels-dev/scoop-wheels, whose template diverged from the draft after the inline-JDK commit (scoop-wheels@3f22250).

• Fix PR: fix(wrapper): bypass cmd-parser on lucli bat-jar + add JDK fallback path scoop-wheels#6 (patches both bucket/wheels.json and bucket/wheels-be.json)
• Tracking issue in the bucket repo: Windows: wheels.cmd wrapper aborts at cmd-parser when calling lucli bat-jar, plus JDK-path fallback needed scoop-wheels#7

Once #6 merges, this repo's build-manifests.py should be re-synced with the bucket so the draft stops drifting — that part stays open here.