Skip to content

Environment not set up on Ubuntu at install #975

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
carols10cents opened this issue Mar 6, 2017 · 11 comments
Closed

Environment not set up on Ubuntu at install #975

carols10cents opened this issue Mar 6, 2017 · 11 comments
Labels

Comments

@carols10cents
Copy link
Member

(moved here from rust-lang/book#404)

@tsingi reported:

Using Ubuntu, after the install the environment was not being sourced at shell startup.

tsingi@tsingi:~$ uname -a
Linux tsingi 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

The init script sets up .profile which doesn't seem to be sourced in Ubuntu when I start a shell.

I copied the PATH line:

export PATH="$HOME/.cargo/bin:$PATH"

to .bashrc and it sources fine.

This should be corrected in the script and/or addressed in troubleshooting. Or you could convince Ubuntu to use .profile by default.

I think this is an issue with rustup and/or rustup docs, and I hope we can figure this out over here rather than having to document it in the book.

This might be related to #211, #556, or #371, but I'm not sure.

@brson
Copy link
Contributor

brson commented Mar 16, 2017

PATH handling needs overhaul completely.

@brson brson added the bug label Mar 16, 2017
@JekoTronik
Copy link

Hi,
I am running Debian Jessie stable. Environment not setup after
curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain nightly

@shepmaster
Copy link
Member

Specifically, we see the Ubuntu issue on Ubuntu 16.04.2 LTX (Xenial) using bash.

@tesuji
Copy link
Contributor

tesuji commented Apr 4, 2019

EDIT: I misunderstood the issue that the users want to use Rust right after
installation without restarting their shell.

When we use curl https://sh.rustup.rs -sSf | sh to install rustup and rust,
we execute the installer script in the new child shell. The question now is
how to alter PATH within a shell script?. Only one solution is
appropriate here, that's to spawn a new shell that contains the altered
PATH. So we include the script below in rustup-init.sh:

export PATH="$HOME/.cargo/bin:$PATH"
exec "$SHELL"

But there is unresolved question here:

  • This will spawn the new shell. So when users type exit in this shell, they will return
    to the parent shell. Is this the behavior that users like or might be surprised?

    Temporary solution is to inform users that rustup-init.sh will spawn a
    new shell after installation.

@kinnison
Copy link
Contributor

kinnison commented Apr 4, 2019

I'm not sure what approach is best. Nominally .profile should be read by all shells (though bash will not read it if .bash_profile exists too. I suppose really we should attempt to detect the right shell and adjust the right file, so .bash_profile if bash is detected, .profile if zsh etc.

@brson
Copy link
Contributor

brson commented May 28, 2019

Just looking through the code now, both .profile and .bash_profile are modified if they exist.

@kinnison
Copy link
Contributor

Yes I just noticed that. In theory we should also support .bash_login but I'm less worried about that one since it seems pretty rare. The OP posted on the 6th March 2017 and .bash_profile specific code has been present since June 24th 2017 That was 1.4.0+32 so I'm guessing that it was in 1.5.0 of rustup.

Do we think this could be closed?

@brson
Copy link
Contributor

brson commented May 28, 2019

The problem I probably have, and I suspect many, is understanding the distinction between a shell and a login shell.

Most people probably just want cargo to work immediately, or to launch a new terminal and have it work, but for most configurations they have to literally log out of their GUI to get .profile to run.

I myself mostly work on WSL and I have no idea when .profile runs, but I've just discovered how to launch a terminal with a login shell (after years of frustration).

The instructions do indicate how to get the current shell immediately working by sourcing .cargo/env.

@kinnison I kinda think this should be closed, but I'm still not happy with the install experience here.

That it only works after a login is very confusing. I'm kinda thinking that putting some code in .bashrc, .zshrc that sources a clever script in ~/.cargo/, that conditionally fixes the environment would be smart.

@brson
Copy link
Contributor

brson commented May 28, 2019

In fact, $CARGO_HOME/env could just be smart in general and conditionally set up cargo if it isn't already. Then source that script from every possible init script.

@brson
Copy link
Contributor

brson commented May 28, 2019

@kinnison I filed another bug about making the post-install setup more robust #1881

@kinnison
Copy link
Contributor

Okay, we'll continue the work from there and I'll close this, thank you @brson.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants