GitSquared / edex-ui

A cross-platform, customizable science fiction terminal emulator with advanced monitoring & touchscreen support.
GNU General Public License v3.0
40.61k stars 2.56k forks source link

'Unknown Proxy Name' Error When Attempting to Run Rust #1124

Closed iamGBOX closed 3 years ago

iamGBOX commented 3 years ago

Technical information

Using version:

Running on:

How comfortable you are with your system and/or IT in general:


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'

unknownproxyname-RUST

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

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 1.24.2 (755e2b07e 2021-05-12)

cargo 1.52.0 (69767412a 2021-04-21)

I can include additional details on my environment at request.

GitSquared commented 3 years ago

Hey there! I think I found something.

First, the error itself is coming from Rustup (GitHub's code search is :fire:), 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:

https://github.com/GitSquared/edex-ui/blob/0fa76464ff089b31fb84a6196ae276c54303356a/src/_boot.js#L229-L236

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.

iamGBOX commented 3 years ago

That's a wild ride! Thanks for your help, and for the builds; they run like a dream. Glad to help however I can!