SCM

6.3.1: File-System Habitat

Where should software reside? Although individually a minor annoyance, cumulatively this question represents many thousands of frustrated user hours spent trying to find support files or guessing where packages need to be installed. Even simple programs require proper habitat; games need to find their score files.

Aren't there standards for this? Some Operating Systems have devised regimes of software habitats -- only to have them violated by large software packages and imports from other OS varieties.

In some programs, the expected locations of support files are fixed at time of compilation. This means that the program may not run on configurations unanticipated by the authors. Compiling locations into a program also can make it immovable -- necessitating recompilation to install it.

Programs of the world unite! You have nothing to lose but loss itself.

The function scm_find_impl_file in `scm.c' is an attempt to create a utility (for inclusion in programs) which will hide the details of platform-dependent file habitat conventions. It takes as input the pathname of the executable file which is running. If there are systems for which this information is either not available or unrelated to the locations of support files, then a higher level interface will be needed.

Function: char *scm_find_impl_file(char *exec_path, char

*generic_name, char *initname, char *sep) Given the pathname of this executable (exec_path), test for the existence of initname in the implementation-vicinity of this program. Return a newly allocated string of the path if successful, 0 if not. The sep argument is a null-terminated string of the character used to separate directory components.

• One convention is to install the support files for an executable program in the same directory as the program. This possibility is tried first, which satisfies not only programs using this convention, but also uninstalled builds when testing new releases, etc.
• Another convention is to install the executables in a directory named `bin', `BIN', `exe', or `EXE' and support files in a directroy named `lib', which is a peer the executable directory. This arrangement allows multiple executables can be stored in a single directory. For example, the executable might be in `/usr/local/bin/' and initialization file in `/usr/local/lib/'.

  If the executable directory name matches, the peer directroy `lib' is tested for initname.

• Sometimes `lib' directories become too crowded. So we look in any subdirectories of `lib' or `src' having the name (sans type suffix such as `.EXE') of the program we are running. For example, the executable might be `/usr/local/bin/foo' and initialization file in `/usr/local/lib/foo/'.
• But the executable name may not be the usual program name; So also look in any generic_name subdirectories of `lib' or `src' peers.
• Finally, if the name of the executable file being run has a (system dependent) suffix which is not needed to invoke the program, then look in a subdirectory (of the one containing the executable file) named for the executable (without the suffix); And look in a generic_name subdirectory. For example, the executable might be `C:\foo\bar.exe' and the initialization file in `C:\foo\bar\'.