### 3.5 Specifying file paths in configuration settings

Path and file names should conform to the requirements listed in §1.1.2 File, directory, and path names, otherwise you risk run-time errors. Additional considerations:

Path separator can be “\” or “/” (except sometimes!)

Paths that contain spaces must be quoted

Most relative paths relate to the project directory

Paths to configuration templates should be absolute

Some relative paths relate to the configuration file location

Paths to other applications must be absolute.

Path separator can be “\” or “/” (except sometimes!)

When you specify a file path in a configuration setting, you can use either a backslash “\” or a forward slash “/” as a separator character. A forward slash is preferred, except in the following cases, where you must use a backslash:.

- Windows system commands; see §43.1 Executing operating-system commands
- Windows command parameters; for example, see §44.11 Archiving deliverables.

In Windows API calls, forward slashes work fine, because the original Windows programmers compiled Windows on VAX/VMS machines.

Note: XML catalog-key path settings must use forward slashes. See §4.1.1 Connecting to XML catalogs

Paths that contain spaces must be quoted

If a path contains any spaces, enclose the entire path in quotes. See §1.1.2 File, directory, and path names.

Most relative paths relate to the project directory

Most path settings (other than those listed in Table 3-1) can be either relative or absolute. Relative file paths can make your conversion project portable. Many support issues arise when a project is moved, after which some buried links stop working.

When you specify a relative file path in a configuration setting, the path is relative to the project directory, with the following exceptions:

- settings listed in Table 3-1
- [Automation]ShipPath, which is relative to the wrap directory; see §44.3 Understanding path values for deliverables.

Paths to configuration templates should be absolute

Settings that reference configuration templates, or other files in the DITA2Go distribution directory structure, should use absolute paths that begin with environment variable %OMSYSHOME%; for example:

Configs = %omsyshome%\d2g\local\config\local_d2htm_config.ini

See §1.3.1 Set up a framework for Omni Systems applications.

Some relative paths relate to the configuration file location

If you specify a relative path in any of the settings listed in Table 3-1, the path is considered to be relative to the location of the configuration file in which the setting occurs. This means that if you move such a setting from one configuration file to another at a different level in your project directory structure, the path will no longer be correct.

If you want project portability, the price is using a fixed directory structure, where both the _config directory (see §39.3.2 Deciding where to keep document-specific configuration files) and the project directory are immediately below the source directory. If you have files all over the place, portability becomes impossible.

Table 3-1 Absolute vs. relative file-path settings

Section | Setting | Absolute or relative file path? | Ref.
[Templates] | All settings | Paths to templates in the DITA2Go distribution should be absolute and start with %OMSYSHOME% | 39.1
Paths to your own template files should be relative to the location of the configuration file in which the setting occurs | 39.5
[Setup] | DTDPath | Absolute path recommended | 4.1.3
[Logging] | LogFileName | Keep setting in project configuration file | 4.2
HistoryFileName | Keep setting in project configuration file | 4.2
EditorFileName | Absolute path required | 4.2
[ConditionOptions] | DitavalFile | Absolute path recommended | 9.1.1
[OmniHelpOptions] | ProjectTemplate | Keep setting in project configuration file | 19.5.7

Paths to other applications must be absolute

File paths to non-DITA2Go executables must be absolute. However, a better way would be to make sure those executables are on your system PATH, so your conversion project is portable.

Previous Topic: 3.4 Understanding the rules for configuration settings

Next Topic: 3.6 Using wildcards in configuration settings

Parent Topic: 3. Editing configuration files

Sibling Topics:

3.1 Working with DITA2Go configuration files

3.2 Editing files with the Configuration Manager

3.3 Understanding where project settings come from

3.4 Understanding the rules for configuration settings

3.6 Using wildcards in configuration settings

3.7 Commenting out configuration sections

3.8 Ending a configuration file

Table of Contents • Index