![]() |
Syntaxe du fichier de définition d'un jeu de classes |
Cette rubrique explique la syntaxe des fichiers de définition de jeu de classes. Il suffit de lire celui-ci que si vous voulez personnaliser le comportement du processus d'optimisation avancée, ou si vous souhaitez mettre en évidence séparément un groupe de fichiers qui n'est pas déjà mis en évidence différemment par iDefrag.
Il s'agit d'un sujet pour utilisateur expérimenté, les utilisateurs ordinaires seront probablement plus intéressés par les informations plus générales sur les jeux de classes dans une autre partie de ce fichier d'aide.
NDLT La syntaxe a été laissée en anglais pour éviter des problèmes de fonctionnement du logiciel.
Beaucoup de choses sur cette page sont cliquables; cliquez dessus pour afficher des informations détaillées sur des points précis de la syntaxe.
A simplified BNF grammar describing the syntax is shown below:
specification ::= (toplevel-stmt <newline>)*
toplevel-stmt ::= class-decl | dispclass-decl | order-stmt | include-stmt
class-decl ::= class <string> { class-spec }
dispclass-decl ::= display class <string> { class-spec }
order-stmt ::= order { class-list }
include-stmt ::= include <string>
class-list ::= <string>+
class-spec ::= (class-spec-stmt <newline>)*
class-spec-stmt ::=
priority <number>
| match match-spec
| locked
| special
| (color|colour) <color>
| sort on property-list
| pre command <string>
| post command <string>match-spec ::=
volume header
| alternate volume header
| journal
| journal information block
| catalog file
| attributes file
| startup file
| extents file
| allocation file
| bad block file
| files where match-exprmatch-expr ::=
( match-expr )
| not match-expr
| match-expr or match-expr
| match-expr and match-expr
| property = value | property != value
| property < value | property > value
| property <= value | property >= value
| property ~= value | property ~!= value
| file is within value
| file isn't within value
| file is fragmented
| file isn't fragmentedproperty-list ::= property (, property)*
property ::=
name
| id
| size
| creator
| type
| content modification date
| attribute modification date
| access date
| creation date
| backup date
| owner
| group
| mode
| admin flags
| owner flags
| resource fork size
| data fork size
| containing foldervalue ::= <string> | <number>
In the notation above, italics indicate “non-terminal symbols” (that is, things that are defined elsewhere in the grammar), bold text is used for literal characters, parentheses (round brackets) for grouping and angle brackets to indicate a token type.
Additionally, “::=” means “is defined as”, ‘|’ is used to indicate an either-or choice (in technical terms, this is referred to as alternation), ‘+’ to indicate one-or-more of the preceding term, and ‘*’ to indicate any number of repetitions of the preceding term.
Strictly speaking, this is not pure BNF, and is also ambiguous (it does not specify the associativity or precedence of the operators defined in match-expr). To resolve the ambiguity, we must also state that:
not has the highest precedence.
The comparison operators =, >, <, >=, <=, !=, ~= and ~!= are all of equal precedence and are non-associative.
and and or have the lowest precedence (and has a slightly higher precedence than or, but most people prefer to use parentheses to explicitly specify the grouping of expressions containing more than one and or or operator).
In addition, and and or are lazy, by which we mean that they are evaluated only as far as is necessary to know the final result. For instance, false and x is always false, regardless of the value of x, whilst true or y is always true, regardless of the value of y. (It is also worth noting at this point that iDefrag supports the synonyms “&&” and “||” for and and or respectively.)
The syntax also supports C and C++ style comments—for instance
/* This is a comment
…that carries on on the next line */// Whereas this comment goes just to the end of the line
Numbers may be specified in hexadecimal, octal, binary or decimal using a C-style notation
012 /* Octal 1 * 8 + 2 = 10 */ 0b1010 /* Binary 1 * 8 + 0 * 4 + 1 * 2 + 0 * 1 = 10 */ 0xa /* Hexadecimal 1 * 10 = 10 */ 10 /* Decimal 1 * 10 + 0 * 1 = 10 */
Strings may contain the usual C escape characters, including
\nnn Binary character denoted by octal value nnn \xnn Hexadecimal character denoted by hex value nn \n Line feed (ASCII 10) \t Tab (ASCII 9) \r Carriage return (ASCII 13) \b Backspace (ASCII 8) \f Form feed (ASCII 12) \\ Backslash
Note that iDefrag supports characters from the extended Unicode set; class set definitions are read in UTF-8, but if the user desires, character escapes can be used to represent Unicode characters rather than actually embedding them in the definition file (e.g. \x2192 is a valid representation of the Unicode rightwards arrow).
In addition, colors may be specified in any of the following forms:
#rgb The color with red, green and blue values given by the hexadecimal values r, g and b (e.g. #333 would be a dark grey, whilst #ff0 is bright yellow) #rrggbb The color with red, green and blue values given by the hexadecimal values rr, gg, and bb (e.g., #e0ffff would be a pale cyan, whilst #00ff00 is bright green) "#rgb" Same as #rgb. "#rrggbb" Same as #rrggbb. "0xrgb" Same as #rgb. "0xrrggbb" Same as #rrggbb. "colorlist:colorname" The color colorname from the system color list colorlist (e.g., "Crayons:Cantaloupe")
Note that colors specified in class set definition files are simply defaults. If the user overrides the color for a class with a given name, their replacement color will be used for any class with that name from any class definition file. Changing the colors of classes using the color panel at run-time does not affect the class set definition files.