Root directory of portable packages is always added to the PATH regardless of RelativeFilePath

[sitiom]

Brief description of your issue

In a machine without developer mode and in a non-admin shell, Portable packages with subdirectories under RelativeFilePath are not properly added to PATH. This is because the root directory of the package is always added to the PATH regardless.

Steps to reproduce

• Ensure developer mode is turned off and not running under an admin shell (symlinking would happen otherwise)
• Install a package whose RelativeFilePath contains subdirectories. Let us install ffmpeg for this example: winget install ffmpeg
• The root of the package is added to the path (%localappdata%\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe\) instead of the actual file path (%localappdata%\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe\ffmpeg-5.1.2-full_build\bin)

Expected behavior

The root directory should not be added to the path but directories relative to the RelativeFilePath (%localappdata%\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe\ffmpeg-5.1.2-full_build\bin).

Actual behavior

The root directory of the package is always added to the PATH regardless of the RelativeFilePath (%localappdata%\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe\) .

Environment

Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.1194
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.0

---

Another question, how are command aliases handled in non-developer mode? What if there are multiple executables in one directory, and you only want to add one of them to the path?

[DanielHabenicht]

I can confirm this. So this basically effects all users who are not developing winget? (Best real life issue for "Works on myour machines" 😆)

On a side note:
In issue #2711 they discuss about how it is currently impossible to execute executables linked to binary (.dlls) one way to solve it is by adding the installed folder directly to the PATH.

So maybe thats a straightforward way to solve it, just add the installed dir to PATH?. (I am not familar with the project and I don't know what other implications this might have, possibly mixing up some references if the added directory contains more than the desired .exe)

[sitiom]

So maybe thats a straightforward way to solve it, just add the installed dir to PATH?. (I am not familar with the project and I don't know what other implications this might have, possibly mixing up some references if the added directory contains more than the desired .exe)

That is precisely the case. You might not want other executables to be added to the PATH. But it is an option.

[DanielHabenicht]

So maybe thats a straightforward way to solve it, just add the installed dir to PATH?. (I am not familar with the project and I don't know what other implications this might have, possibly mixing up some references if the added directory contains more than the desired .exe)

That is precisely the case. You might not want other executables to be added to the PATH. But it is an option.

Maybe adding a filter/selector for files being copied to this directory could solve it? This way only files needed for the program will be copied to the Winget Package Directory.

[rlaphoenix]

This same issue is happening with aria2.aria2, in the exact same way.

[mdanish-kh]

This has been fixed in WinGet v1.5.1081-preview release through PR #3002

cc @denelon

[sitiom]

It would have been great if the fix was backported in https://github.com/microsoft/winget-cli/releases/tag/v1.4.11071

[denelon]

@sitiom we don't take servicing updates lightly. We limit those to the minimum changes necessary since GA (Generally Available) releases have such a large blast radius. We're expecting a 1.5 release candidate build very soon™️. I'd like to release 1.5 at the end of the month.