Goals
- unify configuration lookup logic between packages reliant on Windows, *nix and/or hybrid file tree layout conventions.
- emulate the *nix "system root" with a conveniently configurable user-chosen distro root/installation prefix (e.g.
c:\Rita).
- allow multiple distro roots to transparently coexist (
c:\MyRita, c:\MyRita2, d:\RitaOnPendrive).
- "softcode" distro root selection in every way possible. IOW, no code change / recompilation should be needed to move the distro to another folder or even another drive. (Relative paths within the distro installation can and should follow *nix conventions.)
Suggested behavior
Let's use the package openssh as an example. Then:
- If the path to the configuration file has been passed explicitly (
-f), the directory of the configuration file is considered the configuration directory, and configuration paths are resolved relative to it. This is convenient for debugging and advanced use cases.
- Absent a configuration file passed explicitly,
%RITA% is assumed to be the distro root and the configuration directory is assumed to be %RITA%\etc\ssh
- Absent
RITA defined, and if the binary file path contains bin, the parent of the bin directory is assumed to be the distro root.
- Absent
bin in the binary path, %HOME% is assumed to be the distro root and %HOME%\.ssh is assumed to be the configuration directory for the package.
- Absent
HOME defined, the directory containing the binary file should be considered HOME. I.e. if the binary file is placed in c:\UnixTools, then c:\UnixTools\.ssh should be considered the package configuration folder.
- The current directory of the process being run MUST NOT be considered for configuration lookup purposes in any way.
The wording ("binary file" rather than "executable file") is deliberate. Once the above logic is extracted into a dedicated component for sharing across other components, it can be embodied in a dedicated DLL or a dedicated executable (i.e. sysroot.exe or sysroot.dll). Then it becomes possible to specify the distro implicitly with PATH, canceling out the need for a special environment variable.
The client package will have to provide two relative paths: /etc-relative and %HOME%-relative. The latter should be optional; if it is not provided, it can be inferred by prepending . to the former (i.e. ssh -> .ssh).
Goals
c:\Rita).c:\MyRita,c:\MyRita2,d:\RitaOnPendrive).Suggested behavior
Let's use the package
opensshas an example. Then:-f), the directory of the configuration file is considered the configuration directory, and configuration paths are resolved relative to it. This is convenient for debugging and advanced use cases.%RITA%is assumed to be the distro root and the configuration directory is assumed to be%RITA%\etc\sshRITAdefined, and if the binary file path containsbin, the parent of thebindirectory is assumed to be the distro root.binin the binary path,%HOME%is assumed to be the distro root and%HOME%\.sshis assumed to be the configuration directory for the package.HOMEdefined, the directory containing the binary file should be considered HOME. I.e. if the binary file is placed inc:\UnixTools, thenc:\UnixTools\.sshshould be considered the package configuration folder.The wording ("binary file" rather than "executable file") is deliberate. Once the above logic is extracted into a dedicated component for sharing across other components, it can be embodied in a dedicated DLL or a dedicated executable (i.e.
sysroot.exeorsysroot.dll). Then it becomes possible to specify the distro implicitly with PATH, canceling out the need for a special environment variable.The client package will have to provide two relative paths:
/etc-relative and%HOME%-relative. The latter should be optional; if it is not provided, it can be inferred by prepending.to the former (i.e.ssh->.ssh).