microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.51k stars 823 forks source link

Windows local host PATH not appended when starting with zsh #12235

Open Wakotu opened 2 weeks ago

Wakotu commented 2 weeks ago

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

  1. install zsh, tmux, and zsh4humans in the ubuntu 24.04 WSL distro
  2. change login shell to zsh: chsh -s /usr/bin/zsh
  3. quit docker desktop and wsl (wsl --shutdown).
  4. restart docker desktop
  5. launch a wsl ubuntu distro shell(open a ubuntu tab in windows terminal).
  6. echo $PATH and see value of PATH doesn't contain paths that defined in windows local system.
  7. and I note that if I didn't run docker desktop first, just open a ubuntu tab in windows terminal directly, the tab would crash and close automatically. Then I open a new tab and it runs well with 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

github-actions[bot] commented 2 weeks ago
Diagnostic information ``` .wslconfig found Detected appx version: 2.3.24.0 ```
sirredbeard commented 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?

OneBlue commented 2 weeks ago

@Wakotu: Do you see the same behavior with let's bash ? I wonder if you have something in your zshrc that override $PATH

Wakotu commented 2 weeks ago

@Wakotu: Do you see the same behavior with let's bash ? I wonder if you have something in your zshrc that override $PATH

  1. Everything works well when login shell is bash
  2. I think no. I just extended value of 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.
Wakotu commented 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?

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.

Image

Wakotu commented 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?

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.

dtgagnon commented 2 weeks ago

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.

Wakotu commented 1 week ago

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?

OneBlue commented 1 week ago

@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 commented 1 week ago

@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:

  1. set distro login shell to zsh chsh -s /usr/bin/zsh
  2. zsh4humans zsh framework installed with 'always run in tmux' option enabled.

Run the command without launching docker desktop

command;

  1. wsl --shutdown
  2. 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. Image

Run the command after launching docker desktop

command;

  1. wsl --shutdown
  2. launch docker desktop
  3. 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. Image

OneBlue commented 1 week ago

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 ?

Wakotu commented 1 week ago

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