Most variables participate in the protocol. A few do not, for one reason or another, and it is unlikely that these will be missed. The !attrvars command will produce a list of the variables that participate, the user can check this if necessary.
When a new technology file is being written, variables that are set will generate content. There is no ``default'', and the options in the Write Tech File panel that alter the treatment of ``default definitions'' have no effect on these lines.
The same variables can also be set with the !set lines. If a variable is set multiple times by any means, the last one seen will have precedence. The variables that participate in the protocol but are set with the !set line will not be remembered as having been set. When a technology file is written, the remembered variables are given !set lines in the new file. This is not necessary for variables that participate in the protocol.
Variables are logically divided into classes. Boolean variables are switches that are either set (usually to an empty string) or not set. Other variables we refer to as ``string'' variables. They are set to an arbitrary text string, when set at all.
In the technology file, booleans take the form
VariableName [y| n]which is the same syntax as for boolean keywords. The ``y| n'' symbol implies that one of `y' or `n' should follow the keyword. Actually, `0' (zero), or any word that begins with the letters or sequence (case insensitive) `n', `f', `of' is taken as a false value. Anything else, including no following text, is taken as true (`y' is always redundant). If the second token indicates affirmative, then the variable will be set. If the second token is negative, no action is taken.
String variables take the form
VariableName arbitrary textwhere the variable will be assigned the arbitrary text, with leading and training white space stripped.
The !attrvars command lists the variables that are boolean and string separately, so the user can check this list if unsure of the variable type.
The VariableName in this context is recognized as a known variable name without case sensitivity. In every other context, variable names are case-sensitive. Since this syntax applies only to internal variable names, there is no conflict as there are no such variables that differ only in case.