Open Wakotu opened 2 weeks ago
I was unable to reproduce the issue in quick manner:
hayden@XPS15:~$ sudo apt install zsh -y
...
Unpacking zsh (5.8.1-1) ...
Setting up zsh-common (5.8.1-1) ...
Setting up zsh (5.8.1-1) ...
...
hayden@XPS15:~$ echo $PATH
/home/hayden/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/usbipd-win/:....
Then:
hayden@XPS15:~$ chsh -s /usr/bin/zsh
PS C:\Users\hayden> wsl.exe --shutdown
Restarted Ubuntu. Went through zsh setup. Configured new completion system, but that was all.
Then:
XPS15% echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/usbipd-win/
Could it be something in your zsh config?
@Wakotu: Do you see the same behavior with let's bash ? I wonder if you have something in your zshrc that override $PATH
@Wakotu: Do you see the same behavior with let's bash ? I wonder if you have something in your zshrc that override $PATH
PATH
variable like export PATH="/usr/local/go/bin:$PATH"
. And if I start with bash shell and then invoke zsh shell, PATH
is also fine.I was unable to reproduce the issue in quick manner:
hayden@XPS15:~$ sudo apt install zsh -y ... Unpacking zsh (5.8.1-1) ... Setting up zsh-common (5.8.1-1) ... Setting up zsh (5.8.1-1) ... ... hayden@XPS15:~$ echo $PATH /home/hayden/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/usbipd-win/:....
Then:
hayden@XPS15:~$ chsh -s /usr/bin/zsh
PS C:\Users\hayden> wsl.exe --shutdown
Restarted Ubuntu. Went through zsh setup. Configured new completion system, but that was all.
Then:
XPS15% echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/usbipd-win/
Could it be something in your zsh config?
I guess your're right. WSL worked the same way in my machine in your manner.
My zsh config consists with zsh4humans
and my custom config. It turns out that my custom config didn't lead to anything wrong. I guess there's some action inside zsh4humans
framework that conflicts with wsl windows path initialization process.
But it's strange that zsh4huamns
works well when I login with bash and run zsh.
Also, launch docker desktop before starting a wsl shell is needed for reproducing this bug.
screenshot below.
I was unable to reproduce the issue in quick manner:
hayden@XPS15:~$ sudo apt install zsh -y ... Unpacking zsh (5.8.1-1) ... Setting up zsh-common (5.8.1-1) ... Setting up zsh (5.8.1-1) ... ... hayden@XPS15:~$ echo $PATH /home/hayden/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/usbipd-win/:....
Then:
hayden@XPS15:~$ chsh -s /usr/bin/zsh
PS C:\Users\hayden> wsl.exe --shutdown
Restarted Ubuntu. Went through zsh setup. Configured new completion system, but that was all.
Then:
XPS15% echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/usbipd-win/
Could it be something in your zsh config?
and I notice that only the first zsh session is broken. Exit first session and launch a new zsh session, the second one is fine.
My encounter with this issue has some unique twists, but is similar enough that I think it's worth adding here.
Had an issue with sudo
on NixOS via WSL2 (NixOS uniquely uses a binary path of /run/wrappers/.../sudo
instead of /run/current-system/.../sudo
). If I use right after logging in with zsh as my shell, it fails. Exiting and restarting the session immediately results in the same failure, but waiting for about 15 seconds before restarting allows to work properly. This seems related to relevant paths not mounting before the shell launches.
When dealing with NixOS on WSL2, I found that /run/wrappers/
wasn’t mounted before the shell loaded, causing it to default to binaries in /run/current-system/sw/bin
. Approximately 15 seconds after the shell started, the /run/wrappers/
path would appear. Running exec $SHELL
at that point would refresh the environment, and which sudo
would correctly point to /run/wrappers/bin/sudo
. I haven't fully investigated why the mounting is delayed, but a simple manual workaround is to wait around 20 seconds before running exec $SHELL
to update the path.
I setup similar environment on a machine that runs windows 10 22H2. And that problem occured, too. but a third machine which runs windows 10 22H2, with ubuntu 22.04 wsl2 distro didn't seem to show that problem . I guess that ubuntu 24.04 distro would be the key?
@Wakotu let's look at what's actually happening inside zsh. Could you share the out of:
wsl -d <distro> zsh -x
This should let us see if something happens to $PATH.
@Wakotu let's look at what's actually happening inside zsh. Could you share the out of:
wsl -d <distro> zsh -x
This should let us see if something happens to $PATH.
Preliminaries:
chsh -s /usr/bin/zsh
zsh4humans
zsh framework installed with 'always run in tmux' option enabled.command;
wsl --shutdown
wsl -d ubuntu zsh -x
stdout output: no-docker-init.txt
phenomenon: Enter a tmux session and crashed unexpectedly, with $PATH env var not well initialized.
command;
wsl --shutdown
wsl -d ubuntu zsh -x
stdout output: docker-init.txt
phenomenon: Enter a tmux session with $PATH env var not well initialized. But no crash.
I don't see the "echo $PATH" commands in the output files. Could you run the entire shell session, include the "echo $path" under zsh -x
?
I don't see the "echo $PATH" commands in the output files. Could you run the entire shell session, include the "echo $path" under
zsh -x
?
I think video would be more intuitive. https://github.com/user-attachments/assets/cea5b591-7040-4556-b6c2-a5862dcb55c1
Windows Version
Microsoft Windows [版本 10.0.26100.2161]
WSL Version
2.3.24.0
Are you using WSL 1 or WSL 2?
Kernel Version
Linux version 5.15.153.1-microsoft-standard-WSL2 (root@941d701f84f1) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.37) #1 SMP Fri Mar 29 23:14:13 UTC 2024
Distro Version
24.04
Other Software
Docker Desktop(Windows), version 4.34.3 (170107) zsh in WSL, version 5.9 tmux in WSL, version 3.4 windows terminal, version 1.20.11781.0 zsh4humans(https://github.com/romkatv/zsh4humans) with option 'always run zsh in a tmux session' enabled
Repro Steps
chsh -s /usr/bin/zsh
wsl --shutdown
).echo $PATH
and see value ofPATH
doesn't contain paths that defined in windows local system.PATH
value well initialized.Expected Behavior
$PATH
variable should include paths that are defined in windows local host system.Actual Behavior
$PATH
variable didn't include paths that are defined in windows local host system.Diagnostic Logs
WslLogs-2024-11-04_22-01-51.zip