Closed Speed7811 closed 9 months ago
The mechanism for handling a portable executables path depends on the scope a user installs it in as well as interaction with Developer Mode on Windows.
Developer Mode enabled - symbolic link created. Administrator installed - symbolic link created. User installed - path environment varible modified.
The terminal or CMD window most likely needs to be closed rather than just opening a new window to get the updated path.
@denelon - I think this may actually be a bug in the way PATH is updated in Windows itself. I tested in Windows Sandbox.
1) Opened a non-elevated PowerShell session
2) winget install pingt -s winget
3) Closed PowerShell and re-open
4) Noted that pingt
wasn't available in non-elevated powershell.exe or in elevated powershell.exe
5) Checked that symlink was created - it was
6) cd
to application directory and tried running application directly - ran fine
7) Inspect system environment variables using the system settings dialogue -
a) User PATH updated to include the Links directory - as expected - Used [x] to close
b) Machine PATH not updated to include Links directory - as expected - Used [x] to close
8) Inspect PATH environment variable loaded in powershell.exe
a) Non-elevated - Does not contain links directory
b) Elevated - Does not contain links directory
However, manually triggering a re-save of the environment variables does the trick -
9) Close PowerShell
10) Open "Edit Environment Variables" dialogue - Open "Path" variable for machine scope - Click "Ok" to close
11) Open PowerShell
12) Inspect PATH environment variable loaded in powershell.exe - Links directory now present
13) Call pingt
- Runs successfully
I don't know if there needs to be a flush of some form, or a double check that the changes were applied to the system, but it seems that in some cases, even though the variable appears to be updated and the new value shows in the system settings dialogue and the registry, that the PATH variable doesn't actually get updated.
I have a recording of this behavior if needed
@Trenly - I tried and check it like in your last comment (include the workaround) and I can reproduce it completly.
@Trenly - One question about "ElevationRequirement". I tried this settings in my manifest file but it seems to be ignored. That means if I set "ElevationRequirement" to "elevationRequired", open an unelevated window - I can install my app although it is not elevated. I tried it via winget install --manifest "PATH_TO_MY_MANIFEST" (Hint: Validation was successful). Is this behaviour correct?
@speed7811 that might be a bug. I'm chatting with the engineering team to discuss if we should either fix validation or determine the right way to support it via our implementation.
@denelon - Should I open a separate issue for the "ElevationRequirement"-Topic?
@Speed7811 yes, go ahead. We can at least discuss options or a decision on a separate issue.
@denelon - Done in #3756
Maybe we should adjust the way how we create the links in %USERPROFILE%\AppData\Local\Microsoft\WinGet\Links
in general. Because as you need either elevated permissions or developer mode does it make behave strange, although it is easy to explain.
What if we create a wrapper executable instead a symlink? An very small executeable, which has the target location build-in and executes the target by handing over all provided arguments, environment variables, stdin, stdout, stderr, ...
Benefits:
I'm currently suffering with this behavior in winget-pkgs#123118 (by-side of the fact that .cmd
and .bat
are not supported in general for portable applications 😏).
I think the issue with PATH not getting refreshed from the registry was fixed in #3751.
Hey,
it looks like this is now fixed in #3751. In the current version 1.6.3133 I don't have any problems. Therefore I closed this issue now.
Brief description of your issue
I've a console app "pingt" and want that the user which installed it can use it in an elevated AND unelevated command line window. At the moment this doesn't work.
Steps to reproduce
Repro 1:
This works:
Repro 2:
This works:
Expected behavior
Command should be found on an unelevated and elevated command line window
Actual behavior
Command was not found on an unelevated window
If I do this:
This works in elevated/unelevated window. But I don't want that any user needs to enter it. The package should be installed as simple as possible for the user.
Environment