*Install_Merge

Installer

» *Commands

» *Install_Merge

*Install_Merge

Use

This *Command combines the entries of two obeyfiles (base_file and changes_file), placing the result in another file.

Syntax

*Install_Merge base_file changes_file dest_file

Parameters

Notes

The dest_file may be the same as one of the source files.

The changes_file may optionally contain a set of rules for the positioning of new entry sections, companys or applications. These consist of any number of special one-line entries, starting |Section, |Company or |App, as appropriate. Each of these lines has the following format:

|[Section|Company|App] rule [rule [rule [rule ...]]]

rule is either:

• specifier>specifier meaning create after in file
• specifier<specifier meaning create before in file

The lack of spaces is significant, and must be adhered.

specifier is either:

• case-insensitive single-word section, company or application
• * to refer to:
  • any specifier (when used on the left)
  • all specifiers (when used on the right)

Rules are used from the first appropriate entry in the file to the last, and left-to-right within each line.

Entries from changes_file will be merged one by one into base_file. This will be achieved thus:

• Scan base_file for the first entry with a section matching that of the new entry. If there are none, scan the command line for the first applicable rule
  • If no rule applies, *>* defaults
• Scan all consecutive entries in base_file with the same section for the first one with a company matching that of the new entry
  • If there are none, scan the command line for the first applicable rule
  • If no rule applies, *>* defaults
• Scan all consecutive entries in base_file with the same section and company for the one that also matches the application in the new entry
  • If there is none, scan the command line for the first applicable rule
  • If no rule applies, *>* defaults
  • If there already was such an entry, compare the version number; if the new entry is a matching or earlier version, use the entry from base_file, otherwise use the entry from changes_file.

If dest_file is to be overwritten, it is first copied into the backup directory. Details of the operation are appended to the log file; each successful entry update is listed separately (along with new version number and any applicable old version number).

Examples

Example 1:

The “Add to Apps” Boot window will use this command:
*Install_Merge <Choices$Write>.Boot.PreDesktop tempfile
<Choices$Write>.Boot.PreDesktop

where tempfile contains the line:
|App Configure>*

The section ResApps and company Acorn can be assumed to already exist (they are part of the default PreDesktop file). However, all other Acorn ResApps entries should come first.

Example 2:

The “Run” Boot window will use this command:
*Install_Merge <Choices$Write>.Boot.Desktop tempfile
<Choices$Write>.Boot.Desktop

where tempfile contains the line:
|Section Run>Boot Run>Auto

The new section Run should be created after Boot, or after Auto (“Auto tasks”) if Boot doesn’t yet exist. Positioning of the Acorn Configure entry within the Run section is not expected to be critical.

Example 3:

The nested Wimp installer, were it to be re-written to use this Installer module, would use:
*Install_Merge <Choices$Write>.Boot.PreDesktop changesfile
<Choices$Write>.Boot.PreDesktop

where changesfile contains the lines:

|Section Installation>Comments
|Company Acorn<*

Installation may be a new section on some machines. Acorn should be the first company within the installation section. Since this is, at the time of writing, the first entry in Acorn Installation, we’ll leave ordering of applications to later installers.

In the event that another entry is written at a later date, which needs to be added to PreDesktop after the Wimp installation entry, a clever approach needs to be taken (because there’s a chance the Wimp will be installed at a later time, and because of the default rule >, it would be added afterwards in PreDesktop).

The new installer should first attempt to install an empty entry called Acorn Wimp 0.00 Installation, then install its own entry after the Wimp one. If a genuine Wimp entry already exists, the 0.00 entry is simply ignored. If the Wimp installer were only to be run later, the dummy entry’s position would override the (default) *>* application rule in the above example.

Because of this, non-empty entries must, in every case, always have version numbers of at least 0.01.

See also

• *Install_DeMerge