'Unknown Proxy Name' Error When Attempting to Run Rust
iamGBOX opened this issue · 2 comments
Technical information
Using version:
-
master
(running from GitHub-published source code, currentlyv2.2.8-pre
) -
latest
(latest release, currentlyv2.2.7
) -
vX.X.X
(specify other version)
Running on:
- Linux
- Windows
- macOS
How comfortable you are with your system and/or IT in general:
- I'm kind of lost, honestly
- I know what's up, I could help you run some commands or checks
- My machine is fully under my control, tell me what you need
- I attended Defcon last year
Problem
I'm getting the following error when attempting to run any Rust tools, such as 'cargo' or 'rustup':
unknown proxy name: 'eDEX-UI-Linux-x86_64'; valid proxy names are 'rustc', 'rustdoc', 'cargo', 'rust-lldb', 'rust-gdb', 'rls', 'cargo-clippy', 'clippy-driver', 'cargo-miri', 'rustfmt', 'cargo-fmt'
I wasn't able to find a reference to this sort of error elsewhere on my own, but this was pointed out to me elsewhere.
I'll note that Rust is running as expected outside eDEX-UI without issues.
System Information
uname-a
for my system:
Linux MOONSTONE-Ubuntu 5.8.0-53-generic #60~20.04.1-Ubuntu SMP Thu May 6 09:52:46 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
rustup
version:
rustup 1.24.2 (755e2b07e 2021-05-12)
cargo
version:
cargo 1.52.0 (69767412a 2021-04-21)
I can include additional details on my environment at request.
Hey there! I think I found something.
First, the error itself is coming from Rustup (GitHub's code search is 🔥), and not cargo, which confused me a bit at first.
I've noticed the eDEX-UI-Linux-x86_64
part corresponds to the name of the AppImage.
Looking at the code which pops the proxy error up, it's trying to read arg0
, which in POSIX shells is supposed to be the name of the current executable - for instance:
test.sh
#!/bin/sh
echo $0
shell
(home ~) 21:25:34 ─╮
❯ chmod +x ./test.sh ─╯
(home ~) 21:25:36 ─╮
❯ ./test.sh ─╯
./test.sh
So why would arg0
look like the name of the AppImage? Well when populating the env
for the terminal subprocess in eDEX we actually do this stupid thing:
Lines 229 to 236 in 0fa7646
Object.assign
overwrites properties in the leftmost object with the rightmost one's - so the order we have rn overrides the "clean" env vars with process.env
, the raw env eDEX itself got at launch. Turns out AppImages include a little gift in there:
shell
(~/.config/eDEX-UI) 21:32:27 ─╮
❯ env | grep eDEX-UI-Linux-x86_64 ─╯
ARGV0="./eDEX-UI-Linux-x86_64.AppImage"
Now I still couldn't reproduce the bug, even when removing/changing this env.ARGV0
var, but i use fish
, not zsh
... And as it turns out, zsh
applies special treatment to ARGV0
, injecting it when executing processes: https://github.com/zsh-users/zsh/blob/00d20ed15e18f5af682f0daec140d6b8383c479a/Src/exec.c#L465
We can confirm this is the root cause:
shell
(~/rust-test) 21:39:53 ─╮
❯ cargo run ─╯
Compiling libc v0.2.58
Compiling autocfg v0.1.4
Compiling rand_core v0.4.0
(...)
(~/rust-test) 21:40:08 ─╮
❯ export ARGV0="gotcha bug 🐛" cargo run ─╯
error: unknown proxy name: 'gotcha bug 🐛'; valid proxy names are 'rustc',
'rustdoc', 'cargo', 'rust-lldb', 'rust-gdb', 'rls', 'cargo-clippy',
'clippy-driver', 'cargo-miri', 'rustfmt', 'cargo-fmt'
I'm going to make sure we only forward a clean env
to subprocess from now on.
Thanks for your help in providing debug output/info!
Edit: Here's freshly built AppImages from CI so you don't have to wait for a new release to come out.
That's a wild ride! Thanks for your help, and for the builds; they run like a dream. Glad to help however I can!