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
openssh
as 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\ssh
RITA
defined, and if the binary file path containsbin
, the parent of thebin
directory is assumed to be the distro root.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.HOME
defined, the directory containing the binary file should be considered HOME. I.e. if the binary file is placed inc:\UnixTools
, thenc:\UnixTools\.ssh
should 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.exe
orsysroot.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
).