devbox shell gives no indication #25
Comments
|
@bogosj , may I ask what shell you use? What do you see if you run |
|
Yes, bash. |
|
I tried zsh, same situation: |
|
Yeah, we need to fix on our side. I just wanted to know which shell so I can make sure it works for it. I'll take a look this coming week. |
|
Same issue with the prompt not being overridden on Mac :) |
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I start a
devbox shellI see no visual indication that I'm in the shell, but it definitely is workingThe text was updated successfully, but these errors were encountered: