GentooWSL icon indicating copy to clipboard operation
GentooWSL copied to clipboard

No windows path

Open crramirez opened this issue 4 years ago • 8 comments

Hello,

I was giving a look at your Gentoo build and I found that it doesn't have Windows Path appended:

image

I investigated a bit but I don't find the reason why it is not there. Even if I add:

[interop]
appendWindowsPath=true

It doesn't work

crramirez avatar Sep 05 '21 16:09 crramirez

Huh that's strange. I don't know what causes the windows path to be appended but I'll take a look at other distros that do it and see if I can figure it out.

imaandrew avatar Sep 06 '21 05:09 imaandrew

If I delete this file /etc/profile.env it gets fixed. The issue is related to /etc/profile

crramirez avatar Sep 07 '21 17:09 crramirez

I'm trying to figure out what would be the best fix for this. I can't delete /etc/profile.env since it's recreated everytime env-update is run and that's called by the package manager. My best idea right now is to remove the PATH variable from /etc/env.d/50baselayout since that's where env-update gets it from and adding PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:${PATH}" to /etc/profile. The only problem is this would just prepend the path every time /etc/profile is sourced but I could probably add a check for that too.

imaandrew avatar Sep 10 '21 19:09 imaandrew

You don't need to add the path to the profile. Check /etc/profile in Pengwin or Ubuntu you'll see an if not WSL then add the path.

crramirez avatar Sep 10 '21 19:09 crramirez

Alright I'm a bit confused. I see the check for not running on WSL, but is there any time that check would actually pass? I assume microsoft will always be found in /proc/version

imaandrew avatar Sep 10 '21 20:09 imaandrew

I think that the check won't ever pass even if you are root but I need to confirm that

crramirez avatar Sep 11 '21 09:09 crramirez

So, I ran into this in my Gentoo-on-WSL setup and found this issue while looking for a solution. For others' reference:

/etc/env.d/50baselayout is, indeed what env-update pulls from to generate /etc/profile.env. However, env-update is a python script, not a bash script, and doesn't interpolate constructions like "${SOME_OTHER_VAR}", so you can't do what I tried, which was add 49winpath with WINPATH="${PATH}" and 51winpath PATH=${PATH}:${WINPATH}; the resulting PATH you get after running env-update winds up ending with :${PATH}:${WINPATH}, because env-update dissects the PATH declarations and assembles a :-delimited PATH declaration of its own in /etc/profile.env.

It's also important to point out that the export PATH='...' that env-update emits into line uses ' instead of ", so you can't put any shell-interpreted strings there, either.

The only place I can see where you might plumb the Windows path through is in /etc/profile, where you can save off $PATH before sourcing /etc/profile.env, check /proc/version for WSL2 if desired, and then append your temporary back onto $PATH.

In all honesty, I wouldn't worry too much about multiple sourcings of /etc/profile; it doesn't seem to me like it's something that would happen in the normal course of events.

mikemol avatar Sep 05 '22 17:09 mikemol

In the end, this in /etc/profile served my purposes:

# Load environment settings from profile.env, which is created by
# env-update from the files in /etc/env.d
if [ -e /etc/profile.env ] ; then
        WINPATH=${PATH}
        . /etc/profile.env
        PATH="${PATH}:${WINPATH}"
fi

If I really cared, I could check if WINPATH already existed, and not reassign it if it did.

mikemol avatar Sep 05 '22 17:09 mikemol