Shell is not overridden on MacOS #46
Labels
bug
Something isn't working
Comments
|
Hey @TheGlenn88, we've noticed that in some cases, the Devbox path is not taking precedence over the user's path. We're working to fix this in an upcoming release |
|
Yes, this is the same issue as #17 we're working on a fix that were hoping to have available before the end of the week. |
gcurtis
added a commit
that referenced
this issue
Sep 1, 2022
This fixes an issue where the user's rc (~/.bashrc, ~/.zshrc, etc.) files were prepending to the devbox shell PATH. This can cause the shell to unexpectedly run the non-devbox version of programs. It's especially noticeable with some version managers that point the PATH at their shims so they can control which version of a program is run. The basic steps that result in this issue are: 1. Devbox launches Nix, which sets the PATH to point to the Nix store. 2. From within Nix, we launch the user's default shell. 3. The shell runs the user's init files and stomps on the Nix PATH. Fixing this is a little tricky because there's no straightforward way to run additional commands _after_ the shell runs the init files. Instead, we need to copy the user's init files and append to them. Doing this requires knowing how each shell handles initialization, so we need to special-case the more common shells by performing the following steps: 1. Attempt to detect the user's default shell via the SHELL env var (we may add more sophisticated detection later). 2. If the shell is recognized as bash, zsh, ksh, dash, ash or sh, copy over the user's corresponding init files to a temp directory and append our own commands to it. 3. Build an `exec` shell command that invokes the new shell and tells it to run our temp init file instead of the user's. If we can't detect the shell, we fall back to launching a vanilla Nix shell. If we don't recognize the detected shell, we fall back to launching it without overriding the init files. Finally, since we now have a way of running our own commands in the user's shell, we can change the PS1 prompt to show the user that they're in devbox. Fixes #17, #25, #44, #46.
gcurtis
added a commit
that referenced
this issue
Sep 1, 2022
This fixes an issue where the user's rc (~/.bashrc, ~/.zshrc, etc.) files were prepending to the devbox shell PATH. This can cause the shell to unexpectedly run the non-devbox version of programs. It's especially noticeable with some version managers that point the PATH at their shims so they can control which version of a program is run. The basic steps that result in this issue are: 1. Devbox launches Nix, which sets the PATH to point to the Nix store. 2. From within Nix, we launch the user's default shell. 3. The shell runs the user's init files and stomps on the Nix PATH. Fixing this is a little tricky because there's no straightforward way to run additional commands _after_ the shell runs the init files. Instead, we need to copy the user's init files and append to them. Doing this requires knowing how each shell handles initialization, so we need to special-case the more common shells by performing the following steps: 1. Attempt to detect the user's default shell via the SHELL env var (we may add more sophisticated detection later). 2. If the shell is recognized as bash, zsh, ksh, dash, ash or sh, copy over the user's corresponding init files to a temp directory and append our own commands to it. 3. Build an `exec` shell command that invokes the new shell and tells it to run our temp init file instead of the user's. If we can't detect the shell, we fall back to launching a vanilla Nix shell. If we don't recognize the detected shell, we fall back to launching it without overriding the init files. Finally, since we now have a way of running our own commands in the user's shell, we can change the PS1 prompt to show the user that they're in devbox. Fixes #17, #25, #44, #46.
gcurtis
added a commit
that referenced
this issue
Sep 1, 2022
This fixes an issue where the user's rc (~/.bashrc, ~/.zshrc, etc.) files were prepending to the devbox shell PATH. This can cause the shell to unexpectedly run the non-devbox version of programs. It's especially noticeable with some version managers that point the PATH at their shims so they can control which version of a program is run. The basic steps that result in this issue are: 1. Devbox launches Nix, which sets the PATH to point to the Nix store. 2. From within Nix, we launch the user's default shell. 3. The shell runs the user's init files and stomps on the Nix PATH. Fixing this is a little tricky because there's no straightforward way to run additional commands _after_ the shell runs the init files. Instead, we need to copy the user's init files and append to them. Doing this requires knowing how each shell handles initialization, so we need to special-case the more common shells by performing the following steps: 1. Attempt to detect the user's default shell via the SHELL env var (we may add more sophisticated detection later). 2. If the shell is recognized as bash, zsh, ksh, dash, ash or sh, copy over the user's corresponding init files to a temp directory and append our own commands to it. 3. Build an `exec` shell command that invokes the new shell and tells it to run our temp init file instead of the user's. If we can't detect the shell, we fall back to launching a vanilla Nix shell. If we don't recognize the detected shell, we fall back to launching it without overriding the init files. Finally, since we now have a way of running our own commands in the user's shell, we can change the PS1 prompt to show the user that they're in devbox. Fixes #17, #25, #44, #46.
|
@gcurtis merged a fix. It's going out on the next release. Closing. |
|
@TheGlenn88 this fix is now available in the most recent 0.0.4 release. If you installed devbox with the install script, then it should auto-update to the new version the next time that you run it. Thanks for taking the time to report this bug, and feel free to reopen this issue if you're still seeing the wrong version of Node after updating. |
|
Thanks @gcurtis I’ll test again tomorrow and report my findings. :) |
|
I’ve just managed to test actually and it worked perfectly. Hats off to the smooth experience as well by the way, no messing around. Good job. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I've install Nix, followed by Devbox, upon trying to do a
devbox add nodejs-18_xfollowed by adevbox shell- I get dropped into a new zsh shell but has no access to node 18, it has access to node 16 from my main env.Have I missed something or have I stumbled upon a bug? is there anything I can do to debug?
disclaimer: I had previously installed nix about a year back and didn't do too much with it.
Thanks
The text was updated successfully, but these errors were encountered: