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 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 * 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\’.

---

6.3.2 Executable Pathname

For purposes of finding Init5f4.scm, dumping an executable, and dynamic linking, a SCM session needs the pathname of its executable image.

When a program is executed by MS-DOS, the full pathname of that executable is available in argv[0]. This value can be passed directly to find_impl_file (see File-System Habitat).

In order to find the habitat for a unix program, we first need to know the full pathname for the associated executable file.

Function: char * dld_find_executable (const char *command) ¶

dld_find_executable returns the absolute path name of the file that would be executed if command were given as a command. It looks up the environment variable PATH, searches in each of the directory listed for command, and returns the absolute path name for the first occurrence. Thus, it is advisable to invoke dld_init as:

main (int argc, const char **argv)
{
    …
    if (dld_init (dld_find_executable (argv[0]))) {
        …
    }
    …
}

Note@: If the current process is executed using the execve call without passing the correct path name as argument 0, dld_find_executable (argv[0]) will also fail to locate the executable file.

dld_find_executable returns zero if command is not found in any of the directories listed in PATH.

---

6.3.3 Script Support

Source code for these C functions is in the file script.c. Scripting for a description of script argument processing.

script_find_executable is only defined on unix systems.

Function: char * script_find_executable (const char *name) ¶

script_find_executable returns the path name of the executable which is invoked by the script file name; name if it is a binary executable (not a script); or 0 if name does not exist or is not executable.

Function: char ** script_process_argv (int argc; char **argv) ¶

Given an main style argument vector argv and the number of arguments, argc, script_process_argv returns a newly allocated argument vector in which the second line of the script being invoked is substituted for the corresponding meta-argument.

If the script does not have a meta-argument, or if the file named by the argument following a meta-argument cannot be opened for reading, then 0 is returned.

script_process_argv correctly processes argument vectors of nested script invocations.

Function: int script_count_argv (char **argv) ¶

Returns the number of argument strings in argv.