You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@vasily-kirichenko The easy part is expanding the environment variables once on compile time, i.e. FileSystem<"%SystemRoot%">.Path = @"C:\Windows\". Then, when deploying the compiled program to another machine, the path stays the same, regardless of the actual value of the environment variable. @asd-and-Rizzo is this what you wanted?
I think it would be interesting to also support runtime environment variables: FileSystem<"%Public%">.DynamicPath = @"C:\Users\Public" on standard systems and @"U:\Public" on some other, regardless of the system the program was compiled on. Obviously, DynamicPath can't be [<Literal>]. What do you think?
Things to decide upon
Always expand paths vs. have boolean flag, e.g. FileSystem<"%SystemRoot%", expandEnvVars = true>
Note: C:\%TMP%\%WHY%DID%%YOU%DO.that is a valid name, requiring escaping % is a breaking change.
To include DynamicPath / RuntimePath / ... or not? (Having above flag, provide only if switched on.)
Include expansion for relativeTo parameter?
Include expansion for RelativePath<...> provider?
All things settled, I'd volunteer for implementing.
Is next possible?
Sometimes enterprise admins setups some things which are usually on
C:/
to go to other routes via Environment variables.The text was updated successfully, but these errors were encountered: