Rustup-init fails when fish is installed but without config files generated

[4310V343k]

Problem

I launched a GitHub Codespace, ran curl https://sh.rustup.rs -sSf | sh, got error: could not amend shell profile: '/home/codespace/.config/fish/conf.d/rustup.fish': could not write rcfile file: '/home/codespace/.config/fish/conf.d/rustup.fish': No such file or directory (os error 2)

Even though fish is installed in the codespace, its config is not pre-generated and the default shell is bash.
As I understood after 5 minutes of scrolling the code, rustup only checks if the shell's binary exists, not if the config files exist
This doesn't happen with other shells since their config files are typically located in the home folder

Steps

1. Ensure fish is on PATH
2. Ensure fish's config directory doesn't exist
3. Run rustup with default settings (with modify PATH variable)

Possible Solution(s)

No response

Notes

Looks like conf.d directory is not created automatically even after running fish

Rustup version

Rustup did not install, but

@4310V343k ➜ /tmp/tmp.MNjnDjzYbe $ ./rustup-init -V
rustup-init 1.27.0 (bbb9276d2 2024-03-08)

Installed toolchains

Rustup did not install

[rami3l]

@4310V343k Thanks for sharing with us your diagnosis!

This is indeed a bug with very clear cause, however I'm not sure how we should proceed with it.

Previously we do assume if you have a shell installed we should at least make Rust available in it just in case. Of course we can try to create the directory before writing the file (this looks coherent with what we do with other shells), but will this be too invasive?

cc @djc

[rami3l]

@4310V343k For the moment being, you may work around the problem by simply running something like mkdir -p ~/.config/fish/conf.d/ to force the creation of the influenced directory.

[djc]

Seems alright to me to create ~/.config/fish/conf.d on rustup install if the fish binary exists and the dir does not.

[rami3l]

@4310V343k Does our new build work for you?

[ryan-minato]

Because the above PR just missed the previous release, there is a short-term solution before the next release.
Adding -s -- --no-modify-path after sh can bypass this issue.

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --no-modify-path

[rami3l]

@4310V343k @ryan-minato A new beta release is available, would you mind trying it out?