write_env_script / env_script_all_files wrappers don't pass argv[0]

[micolous]

Output of brew config

HOMEBREW_VERSION: 7.0.3
ORIGIN: https://github.com/Homebrew/brew
HEAD: 99fd9a8eed4ff942c448da0c1f11156302441e4a
Last commit: 11 hours ago
Branch: stable
Core tap: N/A
Core cask tap: N/A
HOMEBREW_PREFIX: /opt/homebrew
Homebrew Ruby: 4.0.7 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/4.0.7/bin/ruby
CPU: 18-core 64-bit arm_sotra
Clang: 21.0.0 build 2100
Git: 2.54.0 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 8.7.1 => /usr/bin/curl
macOS: 26.6.2-arm64
CLT: 26.6.0.0.1781586589
Xcode: 27.0
Metal Toolchain: N/A
Rosetta 2: false

Output of brew doctor

Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed casks are deprecated or disabled.
You should find replacements for the following casks:

  gstreamer-runtime
  wine-stable

Warning: A newer Command Line Tools release is available.
Update them from Software Update in System Settings.

If that doesn't show you any updates, run:
  sudo rm -rf /Library/Developer/CommandLineTools
  sudo xcode-select --install

Alternatively, manually download them from:
  https://developer.apple.com/download/all/.
You should download the Command Line Tools for Xcode 26.6.

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:

  icu4c@77
  pcre

Warning: You have unlinked kegs in your Cellar.
Leaving kegs unlinked can lead to build-trouble and cause formulae that depend on
those kegs to fail to run properly once built.

Run `brew link` on these:
  dotnet
  sdl2

Warning: The following taps are not trusted:
  theseal/ssh-askpass

Homebrew is currently ignoring formulae, casks and commands
from these taps because tap trust is required.
Prefer trusting only the specific formulae, casks or commands you need.
Trust installed formulae from these taps  #with:
  brew trust --formula theseal/ssh-askpass/ssh-askpass
Trust other specific casks and commands with:
  brew trust --cask <user>/<tap>/<cask>
  brew trust --command <user>/<tap>/<command>
Whole-tap trust is broader and includes all current and future formulae,
casks and commands from the listed taps. Trust whole taps with:
  brew trust theseal/ssh-askpass
Untap them with:
  brew untap theseal/ssh-askpass
For more information, see:
  https://docs.brew.sh/Tap-Trust

Warning: /usr/bin occurs before /opt/homebrew/bin in your PATH.
This means that system-provided programs will be used instead of those
provided by Homebrew.

The following tools exist at both paths:
  openssl
  pip3
  python3

Consider setting your PATH for example like so:
  echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zshrc

Warning: Homebrew's "sbin" was not found in your PATH but you have installed
formulae that put executables in /opt/homebrew/sbin.

Consider setting your PATH for example like so:
  echo 'export PATH="/opt/homebrew/sbin:$PATH"' >> ~/.zshrc
This is a Tier 2 configuration:
  https://docs.brew.sh/Support-Tiers#tier-2
You can report issues with Tier 2 configurations to Homebrew/* repositories!
  https://docs.brew.sh/Troubleshooting
Read the above document before opening any issues or PRs.

Description of issue

While this issue affects the rustup formula, I think the cause of the issue is Homebrew itself, and may be affecting other formulae. Fixing it in Homebrew will require a rebuild of every formula that calls env_script_all_files or write_env_script.

rustup provides a set of "proxy binaries", which allow it to select between (potentially multiple) Rust toolchains. Using the upstream builds of rustup, there are symlinks from Rust tools (eg: cargo, rustc, rustdoc) to rustup, which it then dispatches to the actual binaries.

Homebrew/homebrew-core#281103 changed rustup's wrapper scripts from being ordinary symlinks to write_env_script wrappers (via env_script_all_files), in order to set an additional environment variable:

#!/bin/bash
RUSTUP_OVERRIDE_UNIX_FALLBACK_SETTINGS="/opt/homebrew/etc/rustup/settings.toml" exec "/opt/homebrew/Cellar/rustup/1.29.1/libexec/bin/rustc"  "$@"

Unfortunately, these wrappers are not entirely equivalent, because they don't propagate argv[0]:

# Before PR 281103, where there is a symlink:
% ARGV0=rustup /opt/homebrew/Cellar/rustup/1.28.2/bin/rustc which rustc
/Users/.../.rustup/toolchains/stable-aarch64-apple-darwin/bin/rustc

# After PR 281103, where there is a write_env_script wrapper:
% ARGV0=rustup /opt/homebrew/Cellar/rustup/1.29.0_2/bin/rustc which rustc
error: multiple input filenames provided (first two filenames are `which` and `rustc`)

# Current version, where there is a write_env_script wrapper:
% ARGV0=rustup /opt/homebrew/Cellar/rustup/1.29.1/bin/rustc which rustc
error: multiple input filenames provided (first two filenames are `which` and `rustc`)

The error messages above are the same as you'd get calling rustc which rustc, rather than rustup which rustc.

That change broke building Firefox from source, as if its build system detects cargo and/or rustc are rustup wrappers, it tries to resolve the actual binaries (to fix other build problems triggered by rustup's wrappers) by calling them with argv[0] = "rustup".

When rustup's wrappers are ordinary symlinks (as is the case with upstream rustup), this works fine. But it doesn't work with write_env_script wrappers.

I've already written a workaround for Firefox to look for an adjacent rustup binary to cargo and rustc binaries if calling them as rustup fails, but this isn't ideal. Firefox's build system doesn't need to know where "actual rustup" is, unless cargo and/or rustc are rustup wrappers, and those wrappers can't be called with argv[0] = 'rustup'.

(broken) fix

This is broken, because $0 isn't actually argv[0], so it doesn't pass it properly.

write_env_file needs to also add -a "$0" to its exec call, in order to be fully equivalent with calling the binary directly.

For example, a fixed wrapper for /bin/cat would look like:

% cat fake-cat
#!/bin/bash
exec -a "$0" "/bin/cat" "$@"

With -a "$0", calling ./fake-cat --help returns:

./fake-cat: illegal option -- -
usage: cat [-belnstuv] [file ...]

Without -a "$0" (as is current behaviour), calling ./fake-cat --help returns:

/bin/cat: illegal option -- -
usage: cat [-belnstuv] [file ...]

This will require rebuilding every formula that calls env_script_all_files or write_env_script.

[GabrielBaiano]

Hello there!

Really impressive investigation into how the wrapper scripts ended up breaking Firefox's build! Tracing that through moz.configure down to argv[0] handling is awesome work.

I was testing the proposed exec -a "$0" fix, and unfortunately ran into a tricky kernel-level catch that makes this a bit more complicated:

Whenever the OS kernel executes a file with a shebang (#!/bin/bash), it actually discards any custom argv[0] passed by the caller (ARGV0=rustup) before bash even starts. The kernel rewrites the call to /bin/bash <script-path>, so inside /path/to/rustc, $0 will always just be /path/to/rustc — it never receives "rustup".

Because of that:

• exec -a "$0" ends up passing /path/to/rustc as argv[0] to the target binary.
• rustup still sees rustc, tries to run rustc which rustc, and fails with the exact same error.

The only reason it worked in 1.28.2 was because the tools were direct symlinks to a compiled Mach-O binary (rustup-init), and compiled binaries receive the caller's argv[0] directly from the kernel without an interpreter stripping it.

Since any shell script wrapper will hit this same kernel limitation, the cleanest way forward for rustup is probably keeping the proxy tools as direct symlinks to the compiled binary:

1. Either patch/configure rustup at build time in Homebrew so it knows the default fallback settings path natively (avoiding the need for shell wrappers altogether).
2. Or use a tiny compiled C shim binary instead of a shell script so the kernel preserves argv[0].

Hope this helps save some back-and-forth debugging time!

[micolous]

Ah, yeah, the fix I proposed would only work if the shell calls the wrapper, rather than manually setting ARGV0.

[carlocab]

Related: Homebrew/brew#12409