Question about: Programs: Env vars in wildcard paths

[Emi-Emi-Emi]

How does it work and what variables does it use? I tested on both wildcard programs and AppGroups, to see if something was done differently.

But testing it I added %LOCALAPPDATA%\BraveSoftware\Brave-Browser*\Application\brave.exe and nothing.

Then I created a User variable TEST C:\Users\user\AppData\Local\BraveSoftware\Brave-Browser-Nightly\Application and when I added %TEST%\brave.exe and didn't work either.

it only worked if I added it like %TEST%**\brave.exe, but when I deleted the Variable it still worked, so I doubt it is even doing what I think it is doing.

Of course, I still don't know what variables it is supposed to use, if it only grabs User and System variables from registry keys, and then ignores %PATH%, or also can grab the Volatile variables from HKEY_CURRENT_USER\Volatile Environment or if it also suppose to even use the other few ones that are not in registry but SS64 page puts them in the Shell Variable column like PROGRAMFILES or PROGRAMFILES(x86) and ALLUSERSPROFILE / PROGRAMDATA, SYSTEMROOT and so on.

Of course, I still don't know if it needs something else besides the % and it is done differently than what I do in CMD and how exactly how it should work inside Fort.

[tnodir]

1. Env vars can be used as %VAR_NAME%.
2. Env vars are resolved by Fort's Service (if it's running).
3. The resolving code is in EnvManager::readEnvVar().

There is a predefined %FORTHOME% var in Fort Firewall.

You can see all Env Vars for Fort's Service in the System Informer program.
So, %LOCALAPPDATA% of Service is C:\Windows\system32\config\systemprofile\AppData\Local.

[tnodir]

EnvManager::readEnvVar() reads from Registry, because it monitors Env Vars changes and updates them from Registry.

[Emi-Emi-Emi]

Yeah, now everything makes sense with the explanation about variables coming from the Service. I forgot about the service for sure. But of course, services running as 'SYSTEM' means limited variables and no normal users' variables.

Of course SYSTEM variables could be added through registry, but it will be easier to type the whole 'user' path, rather than hack the registry for that.

Anyway, Thanks for the explanation! it is good to understand how it works for any future reference, like when running Fort as non-service 👍

[tnodir]

Of course SYSTEM variables could be added through registry

https://www.howtogeek.com/787217/how-to-edit-environment-variables-on-windows-10-or-11/

[Emi-Emi-Emi]

Oh no no, sorry, in this case I meant the USER - SYSTEM account variables, the ones you can add in HKEY_USERS\S-1-5-18\Environment, the difference would be that these variables would only be available for SYSTEM processes like Services, and not all processes like normal system variables would be.

In the end Services running as SYSTEM always has caused issues, like using SSH and trying to open GUI apps, and then psexec is not enough for the task for many programs. Of course SYSTEM seems to be the better way to allow programs to run for all accounts and before windows 'logs in' so can't complain about it. Also there is the option to run some programs (like Fort) as non-services in any case.

System variables for a 1 account computer like mine makes sense, but depending on situation, I like the use of User, since I hate mixing non-critical variables with System ones, so having some exclusive for services is not a terrible idea.