What if current working directory was used instead of <long package path>

[jazzdelightsme]

I submitted a PR (#256) for the kdenlive standalone installer (7Zip self-extracting archive). It supports the --location switch, so that's good.

Q: But if you don't pass --location, then where does the installer extract to?

A: To an undiscoverable temp path like "C:\Users\username\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet".

Perhaps the download could be performed in that location, but once it's downloaded, it's not great to actually run the EXE from that directory. Perhaps after downloading, the EXE could be moved to winget's current working directory, and be run from there. Then the resulting files that it extracts would be at least slightly more discoverable.

[denelon]

@jazzdelightsme Thanks for the feedback! I've tagged this as a "Feature". There may be some other preferences, but the default of the working directory seems reasonable at first glance.

[jantari]

@jazzdelightsme Thanks for the feedback! I've tagged this as a "Feature". There may be some other preferences, but the default of the working directory seems reasonable at first glance.

I don't think that's a good idea, there is no guarantee that winget/the current user has write-access to their current working directory.

Additionally, there is a long-standing confusing behavior where changing the working directory in PowerShell (which is the shell that winget will mostly be run from) does NOT change/update the Current Directory in the .NET sense. E.g. try this:

1. Open PowerShell, it should start with your user profile path as the initial working directory if not customized
2. Run cd ${env:ProgramData} to change the working directory to somewhere else
3. Observe the prompt and cmdlets like Get-Location as well as the automatic $PWD variable reflect the new working directory
4. Run the .NET method [System.Environment]::CurrentDirectory
5. Observe it was NOT updated and returns the old, initial working directory

So depending on how winget would get the working directory of the user, it would likely unexpectedly be "wrong".

I would suggest just copying to and running rom ${env:TEMP}, but many companies implement AppLocker and or Software Restriction Policies that block executables running from ${env:TEMP} because it's a user-writable directory commonly used by legitimate software and malware alike.

So in the end, the directory has to be configurable and I would not change the current default.

[denelon]

We're getting ready to release a new version with the download/execution directory as %Temp% #1146