Skip to content
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

Windows binaries not in $PATH on fresh wsl2 Debian install #5779

Closed
danpoltawski opened this issue Aug 18, 2020 · 17 comments
Closed

Windows binaries not in $PATH on fresh wsl2 Debian install #5779

danpoltawski opened this issue Aug 18, 2020 · 17 comments
Labels
external Issue exists outside of WSL components

Comments

@danpoltawski
Copy link

Environment

Windows build number: 10.0.19041.0
Your Distribution version: Debian GNU/Linux 10 (buster)
Whether the issue is on WSL 2 and/or WSL 1: 2 - Linux version 4.19.104-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Feb 19 06:37:35 UTC 2020

Steps to reproduce

  • Clean wsl2 install using the instructions without first installing any WSL1 distributions.
PS> dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
PS> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
# restart..
PS> wsl --set-default-version 2
  • Install Debian (buster) from Microsoft store and launch
  • Attempt to use windows binaries, e.g.
$ cat ~/.ssh/id_rsa.pub | clip.exe
-bash: clip.exe: command not found
  • Examining the path, no windows paths are found
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
$ cat /etc/wsl.conf
cat: /etc/wsl.conf: No such file or directory

Expected behavior

Windows binaries are in the $PATH

Actual behavior

No windows locations in $PATH

Note

I recently installed another machine with Debian/buster WSL by first install on WSL1 and converting to WSL2 and the correct windows locations were found which makes me suspicious this may be related to not first going through WSL1 conversion process?

@danpoltawski
Copy link
Author

Similar symptoms on this issue #5296

@licanhua
Copy link
Collaborator

licanhua commented Aug 18, 2020

For Debian, /etc/profile contributed to this problem.

Here is the path definition in /etc/profile

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

You can delete above lines, then wsl --shutdown to restart Debian.

If you would like to keep these lines, you can also append ":$PATH" to each path like below, then wsl --shutdown

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi

@therealkenc
Copy link
Collaborator

Splains things. But what are we calling this? External? Those lines have been in Debian /etc/profile since olden tymes. Did something move, or just no one noticed the Ubuntu vs. Debian $PATH behavioral difference until 12 hours ago.

@benhillis
Copy link
Member

benhillis commented Aug 18, 2020

Debian used to have an item in their profile for WSL, looks like they removed it for some reason. More a question for them - @rhaist is that still you?

IS_WSL=`grep -i microsoft /proc/version`
if test "$IS_WSL" = ""; then

@benhillis benhillis added the external Issue exists outside of WSL components label Aug 18, 2020
@therealkenc
Copy link
Collaborator

fair 'nuff

@rhaist
Copy link

rhaist commented Aug 18, 2020

@therealkenc @benhillis I removed the patched profile file in the latest version of Debian because this lead to some other problems with WSL and VSCode.

I would suggest that either:

  • the WSL runtime alters the PATH itself for all distributions to provide windows binaries
  • MS could provide a howto in the WSL documentation how to alter the path to include the windows binaries

This was the commit for Debian WSL that removed the file. You can restore it from there if you need it @therealkenc:

https://salsa.debian.org/debian/WSL/-/commit/7611edba482fd0b3f67143aa0fc1e2cc1d4100a6

@benhillis
Copy link
Member

@rhaist - This is not possible. Processing the profile is something that the shell does, we have no opportunity to edit process environment after we've launched the shell. We set up the path and this line overwrites it.

@benhillis
Copy link
Member

@licanhua - I'd suggest deleting the lines rather than appending $PATH.

@licanhua
Copy link
Collaborator

@rhaist and @benhillis Can you help to review above docs change? I created a PR to update troubleshooting page

@rhaist
Copy link

rhaist commented Aug 19, 2020

Could someone please reopen this issue to keep track of the fix?

This was the PR by Matheus Castello hinting me that for WSL2 /proc/version no longer contains the string microsoft.

https://salsa.debian.org/debian/WSL/-/merge_requests/2

I will search for another clear identifier and publish an update for the App.

@therealkenc
Copy link
Collaborator

therealkenc commented Aug 19, 2020

@microhobby's patch looks about right. There is no need to runtime test for WSL because in the context (the launcher App) you're on WSL by definition.

@therealkenc therealkenc reopened this Aug 19, 2020
@rhaist
Copy link

rhaist commented Aug 19, 2020

By removing those line you end up with the vanilla /etc/profile shipped with Debian (which I prefer).
Should we keep the distros as vanilla as possible and just create documentation about how people can add windows binaries to their WSL profile if they want?

@microhobby
Copy link

@rhaist as the users in the case of WSL distros assume that this path already has the Windows path appended, I would think it would be better to apply my patch, so we cover this case and the case of a custom kernel without "microsoft" in the CONFIG_LOCAL_VERSION with no further configuration by the end-user.

@microhobby
Copy link

@rhaist maybe another solution:

if [ -z "${WSL_DISTRO_NAME}" ]; then
  if [ "`id -u`" -eq 0 ]; then
    PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
  else
    PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
  fi
fi
export PATH

then we can try to submit this change in mainline and use it in the Debian vanilla ...

@microhobby
Copy link

@rhaist The best now, in my view, would be to revert the commit that removes the custom profile and use the solution above. And later check the case of the changes in the profile of vanilla.

I opened a pull request with this:
https://salsa.debian.org/debian/WSL/-/merge_requests/3

@therealkenc
Copy link
Collaborator

By removing those line you end up with the vanilla /etc/profile shipped with Debian (which I prefer).

It would be great if vanilla Debian /etc/profile removed those PATH= lines, but they have been there for a long time now. I assume such a change is not in the cards. The issue is not unique to WSL. Those lines defeat the default $PATH policy set by any parent of /bin/bash -l including login(1) via /etc/login.defs.

The [ -z "${WSL_DISTRO_NAME}" ] conditional in Matheus' the new patch to the Debian launcher App has the same effect as the lines being deleted (like his original). The conditional doesn't hurt, mind, and maybe has some self-documenting value.

[Trivia: If you chsh(1) your default shell to /usr/bin/tcsh then interop works fine on Debian, because /etc/profile never gets fired and the default $PATH policy is not overwritten.]

@therealkenc
Copy link
Collaborator

therealkenc commented Sep 9, 2020

There are doc PRs in the pipe here and here. TL;DR, if you have the following lines in /etc/profile, delete them.

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi

More discussion can be had over in the discussion forum.

@microsoft microsoft locked and limited conversation to collaborators Sep 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
external Issue exists outside of WSL components
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants