rustup: Installer modifies ~/.profile which is ignored for graphical terminals

Problem When running installer using curl https://sh.rustup.rs -sSf | sh in Debian 10 “Buster”, installer adds a line to modify PATH in ~/.profile. That file is not used at all in graphical terminals, so this is wrong. I would expect modified PATH to be active in both login shells and graphical terminals.

Steps

run curl https://sh.rustup.rs -sSf | sh accepting defaults
restart computer
start graphical terminal, see that PATH has not been modified

Possible Solution(s) The line to modify PATH needs to be added to ~/.bashrc instead of ~/.profile.

Notes

Output of rustup --version: none, as rustup is not in PATH Output of rustup show: none, as rustup is not in PATH

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 19 (17 by maintainers)

Most upvoted comments

OK, should be finishing up here soon after Suddenly, Learning More About Modules while I was futzing with refactoring things, but for note to the future: reading $SHELL won’t work here because rustup-init.sh may pipe to a different shell than the user’s default shell (this is, at minimum, the case on Debian systems).

workingjubilee on May 21, 2020

rbtcollins on Apr 29, 2020

Here’s the results of my investigation of {rc,pro}file usage over the suite of shells that commonly come with Rust supported platforms. I will be including a further expansion of my reasoning in my actual commits, but I thought I would leave the notes here in case some other poor benighted soul trawls this issue.

# POSIX, Non-Specified
/etc/profile
~/.profile

# Bash, Login
/etc/profile
~/.bash_profile || ~/.bash_login || ~/.profile
# Bash, Interactive Non-Login
~/.bashrc

# zsh, Always
/etc/zshenv
($ZDOTDIR | $HOME)/.zshenv
# zsh, On Interactive
($ZDOTDIR | $HOME)/.zshrc
# zsh appears to source .zshrc in interactive shells, even login shells.
# So .zprofile is irrelevant.

# tcsh, Always
/etc/csh.cshrc
~/.tcshrc || ~/.cshrc

workingjubilee on Apr 29, 2020

OK, so apparently MacOS does something different now as of Catalina. I asked a MacOS Catalina user to go over their stuff and for their Terminal.app, their .zshrc was consistently sourced, both by their default and brew installed zsh, and so was their .bashrc (when loading bash). This was universal across all of their terminal apps, actually. As a result I am inclined to think that prioritizing rcfile manipulation (over *profile manipulation) and merely adding an additional caution to Mac users is sufficient, rather than special-casing their behavior overmuch.

I was examining an offered example, another project (starship) handles a similar problem by having an init binary which is eval’d and returns appropriate shell commands. This is slightly spooky to me, but on the other hand it would allow .cargo/env to not become split into several different shell scripts, and to have inspecting the path variable to see if it needs the path added be handled by a Rust program (so it can just use std::env to check the shell’s paths, and then decide to not emit shell commands), so it could be a maintenance boon.

workingjubilee on Apr 29, 2020

I’d suggest that the best thing we could do would be to make .cargo/env be idempotent (i.e. if you source it more than once, it doesn’t add itself to the path over and over) and then simply add instructions to source it from as many places as possible (.bashrc .bash_proifile .profile .zshenv etc)

kinnison on Apr 28, 2020

Yes, that is why I formulated an intention of detecting *_apple_darwin environment and doing something different there.

And I am not a part of wg-rustup either! Yet I am working on fixing it, because no one else has, as wg-rustup effort has mostly been tied up in other tasks. Almost like it’s some sort of community-project driven forward mostly by the effort of volunteers! 💦

workingjubilee on Apr 28, 2020

If I remember correctly, terminal of mac os would be using .bash_profile. It is usually a non-login shell.

xiongmao86 on Mar 23, 2020