Possible to have a strip down PATH?

[absenx]

The internal PATH for w64devkit is a copy of our system appended to the location of w64devkit. This is great as in any tool we call in w64devkit that we may of duplicates of already in our system path, the one in w64devkit take precedence as it’s first as it’s listed first it it’s PATH. However is there a way, like in Msys2, to have w64devkit to have a strip down PATH so that it’s sandboxed for its own tools and such and doesn’t create a copy of system path append or be customized like that?

[skeeto]

What's the MSYS2 way of stripping down PATH? Is this like a special mode, or are you describing its default behavior? This might be a case for the "home" configuration in w64devkit.ini. Pick a location for your isolated environment, in w64devkit.ini use this path as the home directory. In that directory write a .profile that configures the stripped down environment you desire. For example, it might have: PATH="$W64DEVKIT_HOME/bin;$SYSTEMROOT" That is, not derived from the current PATH. It's interesting how Microsoft used to be ridiculously stringy about the size of the PATH variable for no reason: In XP it was limited to 1,024 characters. On my Windows 11 system it's now 721 characters with 10 redundant entries *out of the box*, before any of my local changes. They've almost exceeded their own limit in the base system configuration, mostly through their own sloppiness. Maybe the old limit was a good constraint on Microsoft's own behavior. (This might also need $SYSTEMROOT/system32. I don't know.) The default environment has lots of junk, and you could strip it down even further. The bare minimum is HOME (for w64dk), PATH, SYSTEMROOT, and TEMP. The latter two are required for many basic applications. w64dk sets three variables in src/profile to support GNU configure scripts, if you care about that. Some old discussion here, along with speculation about an option to clear the environment: ***@***.***%3E Seeing the PATH situation, perhaps w64devkit.exe could do some cleanup, removing redundant entries, "case folding" per RtlCompareUnicodeString (e.g. collapse C:/Windows and C:/WINDOWS, both of which appear in my default Windows 11 PATH).

[absenx]

Hi skeeto, so in Msys2 PATH variable has three modes for MSYS_PATH_TYPE. The default mode is "minimal" where Msys2's PATH is set to it's stuff and only the essential system path like C:\\Windows\System32. Then there is "strict", where Msys2's PATH is sandboxed/isolated to itself and does not inherit anything from Windows system PATH. Then there is "inherit", where Msys2's PATH will be set to have all of it's stuff plus everything from the Windows system PATH.

Information can be found here: https://www.msys2.org/wiki/MSYS2-introduction/#path

Currently, w64devkit acts like Msys2's in inherit path type, where it would be w64devkit binaries plus everything from the Windows system PATH. So I basically want to configure w64devkit PATH not to inherit from the Windows system PATH, so it's sandedboxed.

[skeeto]

Ah, interesting. I wanted to know how "minimal" chose its path, and I found this: https://github.com/msys2/MSYS2-packages/blob/ae252e94/filesystem/profile#L28-L45 Which is the way it's been since March 2016. The hardcoded native paths are from the Windows 7 through 10 era. XP has Wbem, but, of course, not PowerShell. So I'm thinking maybe introducing a w64devkit.ini "path type" accepting inherit|minimal|strict, with matching behavior, but defaulting to inherit to match the existing behavior. So that would look like: [w64devkit] path type = minimal Hmm, I'll have to think on this.

[absenx]

For now, as you suggested before, I enabled the home directory in the w64devkit.ini and set home = .\home. Made a home folder in the root of w64devkit, and created .profile file and added PATH="$W64DEVKIT_HOME/bin" in that file. This seemed to worked to have "strict" mode.

Yeah, Msys2 has these path hardcoded to determine to access essential system level application.

Also out of curiosity, in the w64devkit.ini, why is having the home folder disabled by default? And why is the default location for home when enable is ..\home and not .\home?

Loving this project so much by the way, it's much easier to use and handle for development in C and C++!

[skeeto]

439ddd5 is a candidate for the new feature. I'm going to test drive it a bit before merging.

why is having the home folder disabled by default?

So that it falls back on busybox-w32 to decide what to do, which I feel is the most appropriate without an expressed preference.

And why is the default location for home when enable is `..\home` and not `.\home`?

It's easier to upgrade or discard w64devkit if it doesn't hold important data like a home/ directory. So a more useful configuration is an adjacent home directory. Using a relative path demonstrates that even an adjacent home is "portable" and can be moved around with like w64dk (e.g. kept on a thumb drive next to w64dk). There's nothing wrong with "home = home" or even "home = ." which I use for some of my own testing. Combine with "path style = strict" and you've got quite an isolated environment!

Loving this project so much by the way

Thanks, I'm happy to hear it!

[absenx]

439ddd5 is a candidate for the new feature. I'm going to test drive it a
bit before merging.

It looks great! I will also try to test it out myself to see how it works out.

So that it falls back on busybox-w32 to decide what to do, which I feel is
the most appropriate without an expressed preference.
...
It's easier to upgrade or discard w64devkit if it doesn't hold important
data like a home/ directory. So a more useful configuration is an adjacent
home directory. Using a relative path demonstrates that even an adjacent
home is "portable" and can be moved around with like w64dk (e.g. kept on a
thumb drive next to w64dk).
There's nothing wrong with "home = home" or even "home = ." which I use
for some of my own testing. Combine with "path style = strict" and you've
got quite an isolated environment!

That makes a lot more sense. Portability is key, so having the flexibility to configure the /home directory without binding it to the install location is actually a great option, but yeah if there is no problem isolating like that, that's cool too.

Again, thank you skeeto for clearing things up for me, and also working this feature!