feat: Added xonsh shell support

[anki-code]

Resolve #4622

Test:

docker run --rm -it rust

apt update && apt install -y python3 python3-pip && pip install --break-system-packages xonsh

xonsh

git clone -b xonsh_shell3 https://github.com/anki-code/rustup && cd rustup/

# https://rust-lang.github.io/rustup/dev-guide/
cargo build
mkdir home
$RUSTUP_HOME='home' $CARGO_HOME='home' target/debug/rustup-init --no-modify-path -y
source /rustup/home/env.xsh

$PATH.pop(0)  # remove '/usr/local/cargo/bin' from container
which cargo
# /rustup/home/bin/cargo
cargo --version
# cargo 1.91.1

[djc]

Please stop reopening the PR, which loses all the context.

[anki-code]

I believe this PR should work. Thanks for review.
(I've faced first time with that "Squash and merge" button is not the solution and "Update branch" button doing something bad. Also there is no clarifications what to do and what to not do in the dev guide so I stepped on all the rakes here, haha)

[rami3l]

I believe mirroring fish's implementation would be better here. Is there a particular reason to check for XONSHRC instead?

[anki-code]

Because of xonsh is not POSIX compatible it keeps path to bash or zsh in the SHELL env var for compatibility (dependent on OS etc). So we need to detect here that we're in xonsh. Checking for XONSHRC env variable is good enough.

[rami3l]

@anki-code It should be noted however that $SHELL, which usually signifies the login shell, can be set to a non-POSIX shell. This is already the case for other shells such as fish in this file. What do you think about that?

PS: I agree that most of the time this won't matter since the second catch-all will usually trigger.

[anki-code]

@rami3l The big picture:

1. $SHELL can contain any shell and xonsh can be installed as a login shell as well and can set the path to xonsh to $SHELL.
2. But most of tools in the world expect that $SHELL is POSIX. They blindfold grab the value of $SHELL and run POSIX commands there and have errors as result and this can follows to unexpected consequences. This is why it's preferred way to keep POSIX shell in the $SHELL forever.
3. Some shells like zsh and maybe fish has POSIX-compatible mode. They detect POSIX commands and run them mostly without errors. This is why they set itselfs to the $SHELL.
4. So this is why using $SHELL value is not the path for shell checking.

[rami3l]

most of tools in the world expect that $SHELL is POSIX

@anki-code I doubt whether that is the case.

I use fish as my login shell and it doesn't have a POSIX-compatibility mode, so I think myself can count as a data point. From my experience, shell script writers would trust sh as authentically POSIX rather than $SHELL.

Also, a quick GitHub global search seems to support this idea.

However, I guess it's okay to merge it while leaving this thread open. We can always come back when either approach is proven suboptimal, and then we can replace the existing with yours if applicable, for example.

[anki-code]

I use fish as my login shell

You're lucky. My first result from search shows that there is no support for non-posix + support fish so I believe this code will fail or have consequences for non-posix.

Try next examples from search and you'll see that people have no thoughts about this could be another shell. So the probability to have fail with non POSIX in $SHELL exists. I read a report where someone catch Linux distro freezing after rebooting with new $SHELL. So if it's work to you you're lucky. Or may be fish as pretty old shell has more support.

[rami3l]

@anki-code Many thanks for making this PR!

Could you just squash these commits into one so we can merge it?

[anki-code]

@rami3l done