fix: resolve native binaries from local jbang directories

[arnabnandy7]

Fixes #2624.

Native command handling now uses the same location precedence as JAR handling:

1. The startup script directory
2. The local .jbang directory
3. $JBANG_DIR/bin

Within each directory, platform-specific native binaries are preferred over generic binaries. When no native binary is available, startup continues to fall back to jbang.jar.

This change:

• Updates the Bash, CMD, and PowerShell startup scripts.
• Updates App.copyJBangFiles() to copy native binaries from the source directory or its .jbang directory.
• Preserves source-directory precedence when the same binary exists in both locations.
• Documents native binary lookup behavior in installation.adoc.
• Adds tests for Bash, CMD, PowerShell, and application installation copying.

Verification:

• ./gradlew spotlessApply
• ./gradlew test --tests "dev.jbang.cli.TestApp" --tests "dev.jbang.cli.TestScriptNativeLookup"

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (1)

• ai-review

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 0aa67a92-c15c-4327-80ff-21460ce36f8a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

📦 PR Build Available

Install this PR build:

curl -sL https://github.com/jbangdev/jbang-pr-builds/releases/download/pr-2660/jbang.tar | tar xf - && ./jbang/bin/jbang version

Release
| Built from 2e1b36a

[maxandersen]

We need to be careful here. If the user runs ./jbang and that is version 0.123 then it would be bad if it goes and run ~/.Jbang/bin/jbang.bin which is a different version.

Reverse true too - if you run Jbang from path i wouldn't expect Jbang to pick up native binary in my local dir.

[quintesse]

If the user runs ./jbang

But that's what we do now. It will pick the one that's located next to the script, but if that one doesn't exist it will fall back to any installed version of JBang.

Reverse true too

Indeed, that should not happen. Your install would be broken (it would mean that you have a ~/.jbang/bin/jbang but no ~/.jbang\bin\jbang.jar which should not happen)

Btw, unrelated to this PR, but I've never read the line above the changes:

which you typically would not commit to a source code repository

THis is not true, you would actually commit this! Just like you'd do with gradlew and mvnw wrappers

[arnabnandy7]

@maxandersen @quintesse with the current lookup order, a local wrapper that has its own .jbang/jbang.jar could still pick up a native binary from the global installation, potentially running a different JBang version.

I think the safer order is:

1. Look for a native binary beside the invoked launcher.
2. Look in the launcher’s .jbang directory.
3. Fall back to the launcher-local JAR.
4. Only when none of those exist, delegate to $JBANG_DIR/bin/jbang, which can resolve its own matching native binary or JAR.

This also means that invoking the globally installed launcher won’t inspect the project’s local .jbang directory, since lookup remains relative to the invoked script rather than the current working directory.

I’ll update the implementation and documentation to follow this order.