commit b6d82513ce79aa9544c2a29e7a7fdb8ff5369e78 Author: Carsten Larsen Date: Sun Feb 28 22:21:40 2021 +0100 Version 43.3 diff --git a/Installer b/Installer new file mode 100644 index 0000000..0f6f32a Binary files /dev/null and b/Installer differ diff --git a/Installer.guide b/Installer.guide new file mode 100644 index 0000000..1c41113 --- /dev/null +++ b/Installer.guide @@ -0,0 +1,3773 @@ +@database Installer.guide + +@Master Installer.texi + +@Width 72 + + +This is the AmigaGuide® file Installer.guide, produced by Makeinfo-1.55 from +the input file Installer.texi. + + $VER: Installer.guide 1.19 (29.4.96) ©1995-96 by ESCOM AG + +Copyright © 1995-96 ESCOM AG + + This file contains the documentation for the Amiga Installer. It +has been created from the original Installer.doc ASCII file. + + Major reworks were necessary. This work has been done by Heinz +Wrobel. It is dedicated to Joan Thuesen. Additional help with the +text has been provided by Jim Cooper. Thanks, Jim. + + +@Node Main "Installer.guide" +@Next "Copyrights" + +@{B}Installer +*********@{UB} + + This document contains all the information needed to use the Amiga +Installer tool. + + + @{" Copyrights " Link "Copyrights"} + @{" Background " Link "Background"} + @{" Overview " Link "Overview"} + @{" Style Guide " Link "Style Guide"} Read this! + @{" Scripting Language Tutorial " Link "Scripting Language Tutorial"} + @{" Installer Language Reference " Link "Installer Language Reference"} + @{" Installer Language Quick Reference " Link "Installer Language Quick Reference"} + +@{B}NOTE:@{UB} On pre V39 (< Workbench 3.0) AmigaGuide you will see some +funny marks on the screen. They are V39 formatting commands which make +the text look nicer under >=V39. They do not reduce the amount of +information shown in this document. + + +@EndNode + +@Node "Copyrights" "Installer.guide/Copyrights" +@Next "Background" +@Prev "Main" +@Toc "Main" + +@{B}Copyrights & Sentiments +***********************@{UB} + +The Installer and its documentation is ©1995-96 by ESCOM AG. + + Based on previous work by Loren Wilton, the V43 Installer and its +documentation have been created by Heinz Wrobel. This work is +dedicated to Joan Thuesen. + + +@EndNode + +@Node "Background" "Installer.guide/Background" +@Next "Overview" +@Prev "Copyrights" +@Toc "Main" + +@{B}Background +**********@{UB} + + Installation of applications from floppy disks onto a hard disk has +proven to be a very inconsistent and often frustrating endeavor for most +end-users. This has been caused by many factors, some of which are: + + a. Many products do not come with any utility or script to install an + application on a hard disk. + + b. Many products assume a great deal of familiarity with the startup + process of the Amiga and applications, including assigns, device + names (as opposed to volume names), etc. + + c. The installation scripts or utilities included with some products + vary widely in their ability to deal with different environments + and systems. + + + In 1991, Commodore set out to remedy this situation, by developing a +standard tool that developers can include with their products, which +provides the user with a standard way to install applications. The +Installer's features were based on a number of assumptions: + + a. Installation requirements vary widely--some need assigns, some need + new drawers created, some install pieces in system drawers such as + a fonts drawer, a `product' might be just an upgrade and the + installation must check to see which version (if any) they + currently have installed, etc. + + b. Different users have different levels of comfort and expertise when + attempting to install software, and the Installer should be able to + accommodate a range of users. Many installation scripts assume a + great deal of knowledge, which is very intimidating for a novice. + + c. The Installer tool must be very flexible internally, but present a + consistent pleasant graphical user interface to the user that only + shows the user information or prompts that they need to see. The + Installer should be resolution, color and font sensitive. + + d. Writing scripts to install an application will require some effort, + but certainly no more than writing an AmigaDOS shell script + equivalent, and the resulting installation procedure will be more + friendly, flexible, and much better looking than the latter. + + + Amiga Technologies improves the Installer to allow even better and +more versatile Installation procedures while keeping it fairly general. +Many new features have been added during V43 Installer development. + + +@EndNode + +@Node "Overview" "Installer.guide/Overview" +@Next "Style Guide" +@Prev "Background" +@Toc "Main" + +@{B}Overview +********@{UB} + + The Installer is a script driven program, that presents a consistent +installation environment to the end user. The user never sees the +script. Instead they are presented with simple yes/no choices, and may +be asked to specify locations to put things on their system. + + To accommodate different user levels, they can choose to run the +tool in novice, average or expert modes. Scripts can include help text +to explain any choices that the user must make. At each step the user +is given the option of aborting the installation. + + + @{" Standard Invocation " Link "Standard Invocation"} + @{" Initial Actions " Link "Initial Actions"} + @{" Startup Screens " Link "Startup Screens"} + @{" Installation Actions " Link "Installation Actions"} + + +@EndNode + +@Node "Standard Invocation" "Installer.guide/Standard Invocation" +@Next "Initial Actions" +@Prev "Overview" +@Toc "Overview" + +@{B}Standard Invocation +===================@{UB} + + The Installer is normally started from a Workbench Project icon +which has the same name as the script to interpret and has a default +tool of Installer. A number of tooltypes are available to modify the +operation of the Installer: + +`SCRIPT' + Path to a script file to be used with Installer. + +`APPNAME' + Name of the application being installed (appears in the startup + screen). This MUST be given. + +`MINUSER' + The minimum possible operation mode of the installation for a + script. This will be either NOVICE (all decisions made by + Installer), AVERAGE (only important decisions made by user) or + EXPERT (user confirms almost all actions). The Default is NOVICE. + +`DEFUSER' + Indicates which operation mode button should be initially + selected. Same values as MINUSER, with the value of the MINUSER + tooltype being the default (which will be NOVICE if MINUSER not + defined). + +`NOPRINT' + If set to FALSE, then the printer option in the log file settings + will be ghosted. + +`PRETEND' + If set to FALSE, indicates that PRETEND mode not available for + this script. + +`LANGUAGE' + Used to set the variable `@language'. The default value for + `@language' is the name of the current locale or `"english"' if + there isn't any available. The use of this variable is left up to + the install script and should be used to adapt the language for + the script's messages to the chosen information. Note that with + Installer V42 and better, the current locale as set by the OS will + automatically be used if no language has been specified. This + tooltype should probably only be used to force a certain language + while testing a script or when a system with OS 2.04 is expected + to be the target. For the latter, it is recommended that you use + the `getversion' command to check the OS version. + +`LOGFILE' + The name of the log file that the Installer should use. This must + be a full path. The default is `install_log_file'. + +`LOG' + In NOVICE mode the default is to create a log file (to disk). If + this tooltype is set to FALSE, the creation of a log file in + NOVICE mode is disabled. + + Although the Installer can be started from the Shell, that is not the +recommended mode. Shell invocation is provided mainly for script +debugging purposes. The command template is: + + `SCRIPT,APPNAME,MINUSER,DEFUSER,LOGFILE,LANGUAGE,NOPRETEND/S, +NOLOG/S,NOPRINT/S' + + +@EndNode + +@Node "Initial Actions" "Installer.guide/Initial Actions" +@Next "Startup Screens" +@Prev "Standard Invocation" +@Toc "Overview" + +@{B}Initial Actions +===============@{UB} + + The first thing the Installer does is to compile the installation +script into an internal format that can be easily interpreted. If +there are syntax errors in the script, they will be caught during this +phase. + + +@EndNode + +@Node "Startup Screens" "Installer.guide/Startup Screens" +@Next "Installation Actions" +@Prev "Initial Actions" +@Toc "Overview" + +@{B}Startup Screens +===============@{UB} + + Next, the Installer asks the user what Installation Mode to run in, +either NOVICE, AVERAGE or EXPERT. If the user chooses NOVICE, they +will not be asked any more questions (although they may be requested to +do things). In the other user levels, a second display appears asking +the user if he wants to install "for real" or "do a dry run", and if he +wants a transcription of the installation process written, and if so, +whether to a file or to the printer. In EXPERT mode, the user should be +asked for every configuration option like installation drawers, while +only the most important questions will be asked in AVERAGE mode. + + +@EndNode + +@Node "Installation Actions" "Installer.guide/Installation Actions" +@Prev "Startup Screens" +@Toc "Overview" + +@{B}Installation Actions +====================@{UB} + + Now the Installer interprets its internal version of the script. Any +commands that call for a user interface will cause the Installer to +algorithmically generate a display, always including buttons to allow +for context sensitive help and aborting the installation. + + +@EndNode + +@Node "Style Guide" "Installer.guide/Style Guide" +@Next "Scripting Language Tutorial" +@Prev "Overview" +@Toc "Main" + +@{B}Style Guide +***********@{UB} + + Making an installation script for any typical application is fairly +easy with Installer 43.2. But to make a really great installation, +please adhere to the rules outlined below: + + · Installer V43 provides some new features over older versions like + better return values for certain statements or optional + proportional rendering for choices. The minimum version necessary + is marked in the respective descriptions. @{B}Please check the + variable `@installer-version' before using these new + features@{UB}. This variable will default to 0 with old versions + of Installer like V1.24, so it is safe and easy to check. Please + do not do an exact equality check. Check for a minimum revision, + just like with libraries. + + · Starting with V42 there are some reasonable guidelines for naming + things. Please adhere to them or upgrading Installer will be very + hard. Don't use the `@' sign for your variables. This sign marks + installer system variables. Please @{B}do@{UB} use a prefix for + your variable names like `#' and name your procedures carefully by + using a prefix like `P_'. Names without a prefix may collide with + future enhancements to Installer. + + · Always, always, always set up meaningful help texts within your + install script. + + · Don't install parts of your application into the standard OS + drawers like `DEVS:', `SYS:', or `FONTS:' unless absolutely + necessary. Many people try to keep their OS installation and + applications separate for easier updates. Never forget that + `PROGDIR:' might be what you really want. + + · If you can't keep needed files together, at least leave a way to + change the destination to something other than e.g. `LIBS:'. + + · Always, always, always allow for a deinstallation in your script. + This is another reason to avoid spreading files around too much. + + · If you are installing or deinstalling libraries, take care that + you don't simply overwrite an existing library or delete it when + some other program might have a need for it. If in doubt ask the + USER, @{B}if@{UB} she is not a NOVICE. + + · Don't keep the user waiting if it is not necessary. If your + application fits on one disk, ask all necessary questions + @{B}first@{UB}, and install the files afterwards. + + · If you have to ask the user for an application directory, make + very clear if your script will create the application directory + there or if the user has to create and specify the directory + himself. This has been the source of much confusion in many + scripts. + + · Don't ask any questions in NOVICE mode. If you absolutely have to + ask questions, don't support NOVICE mode. Any NOVICE mode + installation should be capable of running successfully without user + interaction. + + · Make a difference between AVERAGE and EXPERT mode. In EXPERT mode + the user should be able to confirm just about everything. In + AVERAGE mode, only very important questions should be asked. Do not + let AVERAGE and EXPERT be equal. Give the expert user somethig to + work with and don't confuse the average user. + + +@EndNode + +@Node "Scripting Language Tutorial" "Installer.guide/Scripting Language Tutorial" +@Next "Installer Language Reference" +@Prev "Style Guide" +@Toc "Main" + +@{B}Scripting Language Tutorial +***************************@{UB} + + The script language of the Installer is based on LISP. It is not +difficult to learn, but requires a lot of parentheses. An Installer +script can easily be made to look very readable. + + + @{" Basic Elements " Link "Basic Elements"} + @{" Escape Characters " Link "Escape Characters"} + @{" Symbols (Variables) " Link "Symbols (Variables)"} + @{" Types of Symbols " Link "Types of Symbols"} + @{" Statements " Link "Statements"} + @{" Data Types " Link "Data Types"} + @{" Special Features " Link "Special Features"} + @{" Miscellaneous " Link "Miscellaneous"} + + +@EndNode + +@Node "Basic Elements" "Installer.guide/Basic Elements" +@Next "Escape Characters" +@Prev "Scripting Language Tutorial" +@Toc "Scripting Language Tutorial" + +@{B}Basic Elements +==============@{UB} + + There are only a few basic elements of the Installer language. Here +is a list of these basic elements with a few examples each. + +decimal integers + `5', `32769', `-3' + +hexadecimal integers + `$a000', `$FB' + +binary integers + `%0010010', `%11' + +strings + `"Hello"', `'Hello'' + +symbols + `#x', `#loopvar', `P_funcfoo' + +comments + `; this is a comment ( )' + +`( )' + for statement definition + +space (or any white space) + delimits symbols + + +@EndNode + +@Node "Escape Characters" "Installer.guide/Escape Characters" +@Next "Symbols (Variables)" +@Prev "Basic Elements" +@Toc "Scripting Language Tutorial" + +@{B}Escape Characters +=================@{UB} + +Escape characters are supported as in the C++ language: + +`\\n' + newline character + +`\\r' + return character + +`\\t' + tab character + +`\\h' + horizontal tab character (V42.6) + +`\\v' + vertical tab character (V42.6) + +`\\b' + backspace character (V42.6) + +`\\f' + formfeed character (V42.6) + +`\\"' + double quote + +`\\'' + single quote + +`\\\\' + backslash + +`\\ooo' + some octal number `ooo'. You can use `\\0' to get a NUL character. + (V42.6) + +`\\xXX' + some hex number `XX'. (V42.6) + +@{B}NOTE:@{UB} Depending on the AmigaGuide or MultiView version you are +using, you might see an additional backslash character where there +should only be one. This should show you one backslash: `\\'. And this +should show two of them: `\\\\'. + + +@EndNode + +@Node "Symbols (Variables)" "Installer.guide/Symbols (Variables)" +@Next "Types of Symbols" +@Prev "Escape Characters" +@Toc "Scripting Language Tutorial" + +@{B}Symbols (Variables) +===================@{UB} + + A symbol is any sequence of characters surrounded by spaces that is +not a quoted string, an integer or a control character. This means +that symbols can have punctuation marks and other special characters in +them. The following are all valid symbols: + + · `x' + + · `total' + + · `this-is-a-symbol' + + · `**name**' + + · `@#__#@' + + When naming variables, you should not use `@' as prefix for your +names, but you should select a prefix like `#' to avoid collisions with +future Installer enhancements. + + +@EndNode + +@Node "Types of Symbols" "Installer.guide/Types of Symbols" +@Next "Statements" +@Prev "Symbols (Variables)" +@Toc "Scripting Language Tutorial" + +@{B}Types of Symbols +================@{UB} + +There are three types of symbols: + + a. user-defined symbols. These are created using the `set' function. + + b. built-in function names. These include things like `+' and `*' as + well as textual names such as `delete' or `rename'. + + c. special symbols. These are variables which are created by the + Installer before the script actually starts to run, and are used + to tell the script certain things about the environment. These + symbols always begin with an `@' sign. An example is + `@default-dest' which tells you the default directory that was + selected by the Installer. + + + For naming conventions, please check the @{"Style Guide" Link "Style Guide"}. + + +@EndNode + +@Node "Statements" "Installer.guide/Statements" +@Next "Data Types" +@Prev "Types of Symbols" +@Toc "Scripting Language Tutorial" + +@{B}Statements +==========@{UB} + +The format of a statement is: + + (operator ...) + +A statement to assign the value `5' to the variable `#x' would be: + + (set #x 5) + + You can read this as "set `#x' to 5". Note that the variable `#x' +does not have to be declared - it is created by this statement. + + Note that there is no difference between operators and functions - +the function @{"`set'" Link "s_set"}, and the arithmetic operator `+' are both used +exactly the same way. + + Combining statements: A statement can be used as the operand to +another statement as follows: + + (set #var (+ 3 5)) + + In this case, the statement `(+ 3 5)' is evaluated first, and the +result is 8. You can think of this as having the `(+ 3 5)' part being +replaced by an 8. So now we are left with: + + (set #var 8) + +which is the same form as the first example. + + Note that the `(+ 3 5)' part actually produced a value: 8. This is +called the @{B}result@{UB} of the statement. Many statements return +results, even some that might surprise you, such as `set' and `if'. + + +@EndNode + +@Node "Data Types" "Installer.guide/Data Types" +@Next "Special Features" +@Prev "Statements" +@Toc "Scripting Language Tutorial" + +@{B}Data Types +==========@{UB} + + All data types in the Installer are dynamic, that is to say the type +of a variable is determined by the data it contains. So if you assign +the string `"Hello, World"' to the variable `#x', then `#x' will be of +type STRING. Later you can assign an integer to `#x' and `#x' will be +of type INTEGER. When using variables in expressions, the interpreter +will attempt to convert to the proper type if possible. + + Special forms: There are two exceptions to the form of a statement. +The first type is used for string substitution: If the first item in +parentheses is a text string rather than a function name, the result of +that clause is another string that is created by taking the original +string and performing a C-style `sprintf'-like formatting operation on +it, using the other arguments of the statement as parameters to the +formatting operation. + +Thus the statement: + + ("My name is %s and I am %ld years old" "Mary" 5) + +Becomes: + + "My name is Mary and I am 5 years old" + +@{B}NOTE:@{UB} since the formatting operation uses the ROM `RawDoFmt()' +routine, decimal values must always be specified with `"%ld"' rather +than `"%d"' (The interpreter always passes numeric quantities as 32 bit +longwords). Note that a variable containing a string may be used +rather than the string itself. + + The second type of exception occurs if the elements in parentheses +are themselves statements in parentheses. In this case, the interpreter +assumes that all the elements are statements to be executed +sequentially. + + For example, this statement sets the value of three different +variables: `#var1', `#var2', and `#var3'. + + ((set #var1 5) (set #var2 6) (set #var3 7)) + + What this feature does is allow the language to have a block +structure, where an `if' statement can have multiple statements in its +`then' or `else' clause. Note that the result of this statement will +be the result of the last statement in the sequence. + + Complex statements: Here is an example of how statements in the +script language can be combined into complex expressions. We will +start with an `if' statement. The basic format of an `if' statement is: + + (if []) + + The condition should be a statement which returns a value. The +`then' and optional `else' parts should be statements. Note that if the +`then' or `else' statements produce a result, then the `if' statement +will also have this result. + + Our first example is a rather strange one: Using an `if' statement +to simulate a boolean `not' operator. Note that there are actually +easier ways in the script language to do this. + + (set #flag 0) ; set a flag to FALSE + + (set #flag (if #flag 0 1)) ; a Boolean NOT + + Basically, the `if' statement tests the variable `flag'. If flag is +non-zero, it produces the value `0'. Otherwise, the result is `1'. In +either case, `flag' is set to the result of the `if' statement. + + Now, let's plug some real statements into our `if' statement. + + (if #flag ; conditional test + (message "'flag' was non-zero\n") ; "then" clause. + (message "'flag' was zero\n") ; "else" clause. + ) ; if ; closing parenthesis + + Note the style of the indenting. This makes for an easier to read +program. The preferred indent is four spaces. + + Now, we'll add a real condition. `=' tests for equality of the two +items. + + (if (= #a 2) ; conditional test + (message "a is 2\n") ; "then" clause + (message "a is not 2\n") ; "else" clause + ) ; if ; closing parenthesis + + Finally, just to make things interesting, we'll make the `else' +clause a compound statement. Note the extended use of parentheses to +generate exactly the two needed clauses. Installer won't check things +if you mess up here! + + (if (= #a 2) ; conditional test + ( ; "then" clause + (message "a is 2\n") + ) + ( ; "else" compound statement + (message "a is not 2\n") + (set #a 2) + (message "but it is now!\n") + ) ; end of compound statement + ) ; if ; end of if + + +@EndNode + +@Node "Special Features" "Installer.guide/Special Features" +@Next "Miscellaneous" +@Prev "Data Types" +@Toc "Scripting Language Tutorial" + +@{B}Special Features +================@{UB} + + When the Installer starts running, it attempts to determine the best +place to install the application. Any volume named `WORK:' is given +preference, as this is the standard way that an Amiga comes configured +from Amiga Technologies. Starting with V42 the largest writable +partition available will also be under consideration as default +destination. This covers the typical cases. + + There are two keyboard shortcuts. Whenever there is a `Help' button +active, pressing the HELP key will also bring up the help display. +Whenever there is an `Abort' button active, pressing ESC brings up the +abort requester. Also, whenever the Installer is @{B}busy@{UB}, +pressing ESC brings up the abort requester - there is text is the title +bar to that effect. + + If an application must have assigns or other actions performed during +system boot, the Installer will add these to a file named +`S/User-Startup' on the boot volume. If this file isn't available, +`S:User-Startup' will be tried. The Installer will then add the lines + + if exists S:user-startup + execute S:user-startup + endif + + to the user's `Startup-Sequence'. The Installer will attempt to +determine the true boot volume of the system when looking for the +`Startup-Sequence' and `User-Startup'. It can handle any AmigaDOS +scripts executed from `Startup-Sequence' up to 10 levels of nesting. + + The Installer can create an assign to just a device, volume or +logical assignment. This comes in handy when you want to update an +application which comes on a volume named `MyApp:', but the installed +version is in a directory with the logical assign `MyApp:'! + + The Installer always copies files in the AmigaDOS `CLONE' mode, +meaning all the protection bits, filenotes and file dates are +preserved. When copying files the Installer gives a "fuelgauge" +readout of the progress of the copy. + + The Installer can find the version number of any executable file +that has either a RomTag with an ID string (such as libraries and +devices) or has a version string conforming to that given in the Amiga +User Interface Style Guide. The Installer can also checksum files. + + +@EndNode + +@Node "Miscellaneous" "Installer.guide/Miscellaneous" +@Prev "Special Features" +@Toc "Scripting Language Tutorial" + +@{B}Miscellaneous +=============@{UB} + + To perform a set of actions on all the contents of a directory +matching a pattern you can use the `foreach' operator. To perform a +set of actions on an explicit set of files, the following Installer +statements can be used as a template: + + (set #n 0) + (while (set thisfile (select #n "file1" "file2" "file3" "")) + ( + (set #n (+ #n 1)) + (... your stuff involving this file ...) + ) + ) ; while + + Note that an empty string is considered a FALSE value to any +condition operator. + + To run an external Shell command which normally requires user input, +redirect the input from a file with the needed responses. For example, +to format a disk one could combine the statement shown below with a +file which contains only a newline character. + + (run "format [ ...]) + + Set the variable `' to the indicated value. If `' +does not exist it will be created. Set returns the value of the last +assignment. + +@{B}NOTE:@{UB} All variables are typeless, and any variable may be used +wherever a string could be used. All variables are global. For naming +conventions, please check the @{"Style Guide" Link "Style Guide"}. + + The `set' statement can be used to convert a string to an integer +value: + + (set (+ )) + + To do the reverse, use @{"`cat'" Link "f_cat"}. + + +@EndNode + +@Node "s_symbolset" "Installer.guide/s_symbolset" +@Next "s_makedir" +@Prev "s_set" +@Toc "Statements (Ref)" + +@{B}The `symbolset' statement (V42.9) +---------------------------------@{UB} + + (symbolset [ ...]) + + Set the variable that is named by the contents of the string +variable or expression `' to the indicated value. If the +variable that `' names does not exist, it will be created. +The statement `symbolset' returns the value of the last assignment. + + Together with the function @{"`symbolval'" Link "f_symbolval"}, this function is intended to +allow somewhat dynamic handling of variable names, e.g. to create +variables with an arbitrary index in the name. + +@{B}NOTE:@{UB} You should read the description of @{"`set'" Link "s_set"}, as the rest of +the semantics are the same. + + +@EndNode + +@Node "s_makedir" "Installer.guide/s_makedir" +@Next "s_copyfiles" +@Prev "s_symbolset" +@Toc "Statements (Ref)" + +@{B}The `makedir' statement +-----------------------@{UB} + + (makedir ) + + Creates a new directory. Starting with Installer V42.9, this +statement will try to create the complete path with all specified +intermediate directories. Parameters: + +`prompt' + tell the user what's going to happen. + +`help' + text of help message + +`infos' + create an icon for directory + +`confirm' + if this option is present, the user will be prompted, else the + directory will be created silently. + +`safe' + make directory even if in PRETEND mode + + +@EndNode + +@Node "s_copyfiles" "Installer.guide/s_copyfiles" +@Next "s_copylib" +@Prev "s_makedir" +@Toc "Statements (Ref)" + +@{B}The `copyfiles' statement +-------------------------@{UB} + + (copyfiles ) + + Copies one or more files from the install disk to a target +directory. Each file will be displayed with a checkmark next to the +name indicating if the file should be copied or not. Note that a write +protected file is considered "delete protected" as well. Parameters: + +`prompt' +`help' + tell the user what's going to happen. + +`source' + name of source directory or file. + +`dest' + name of destination directory, which is created if it doesn't + exist. Note that both source and dest may be relative pathnames. + +`newname' + if copying one file only, and file is to be renamed, this is the + new name. + +`choices' + a list of files/directories to be copied (optional) + +`all' + all files/directories in the source directory should be copied. + +`pattern' + indicates that files/directories from the source dir matching a + pattern should be copied. The pattern should be no more than 64 + characters long. Note that only one of `choices', `all' or + `pattern' should be used at any one time. + +`files' + only copy files. By default the Installer will match and copy + subdirectories. + +`infos' + switch to copy icons along with other files/directories. + +`noposition' + reset the position of every icon copied. + +`fonts' + switch to not display `.font' files, yet still copy any that match + a directory that is being copied. + +`nogauge' + don't display the status indicator. + +`(optional