Fix has_local to not search PATH for external 'local' command

[harriiinnii]

Problem

has_local() in rustup-init.sh is used to detect whether the shell has a builtin local keyword. On shells that lack it, the function falls through and the script aliases local to typeset.

However, if the shell has no builtin local and an executable named local happens to exist somewhere in $PATH, that external command would be found and used instead — making has_local return success incorrectly. Any subsequent local usage would then invoke that external command rather than the typeset alias.

Fix

Set PATH= before the local call inside has_local. This prevents the shell from searching $PATH for a local executable: on shells with a builtin local the call succeeds as before, and on shells without it the call correctly fails even if an external local exists in $PATH.

has_local() {
    # shellcheck disable=SC2034  # deliberately unused
    PATH= local _has_local
}

Fixes #5009

[rami3l]

@harriiinnii Oops, it seems like your change is not a pure refactoring step? Would you mind doing some more digging?

[rami3l]

Maybe try (PATH= local _has_local)?

View changes since the review

[harriiinnii]

Thanks for the review, @rami3l. A couple of things I want to address:

The PATH= change is intentional, not cosmetic. On shells without a builtin local (e.g. early Busybox ash), if an executable named local exists somewhere in $PATH, the current code would find it via PATH lookup and incorrectly return success from has_local. Setting PATH= before the call prevents that false positive — the function correctly fails, and the alias local=typeset fallback fires as intended. So yes, it does change behaviour, but only for the pathological case where local is a PATH-shadowing external command. That's exactly the bug described in #5009.

Accidental file mode change: I noticed this commit also changed rustup-init.sh from mode 100755 to 100644 — that was unintentional (likely a git config issue on my end). I can't fix the mode via the GitHub web API, but the easiest remediation is:

git checkout --theirs rustup-init.sh   # restore mode from main
git add rustup-init.sh
git commit --amend --no-edit
git push --force-with-lease

Or I can re-open the PR from a clean branch if you prefer. Let me know how you'd like to proceed.

[rami3l]

@harriiinnii You are not supposed to be copy-pasting from an LLM chat which is in direct conflict with our contribution guidelines.

[daniel-pfeiffer]

Conflicting with the guidelines is one thing. Offering a correct fix is the other. IMHO the latter weighs more!

Not clear why rami3l suggests suggests adding parens, without any motivation. Is it just a misunderstanding of this Shell syntax? Or are there Shells that have problems with this common syntax?