XMLIF(1) xmlif XMLIF(1)NAME
xmlif - conditional processing instructions for XML
SYNOPSIS
xmlif [attrib=value...]
DESCRIPTION
xmlif filters XML according to conditionalizing markup. This can be useful for formatting one of several versions of an XML document
depending on conditions passed to the command.
Attribute/value pairs from the command line are matched against the attributes associated with certain processing instructions in the
document. The instructions are <?xmlif if?> and its inverse <?xmlif if not?>, <?xmlif elif?> and its inverse <?xmlif elif not?>, <?xmlif
else?>, and <?xmlif fi?>.
Argument/value pairs given on the command line are checked against the value of corresponding attributes in the conditional processing
instructions. An `attribute match' happens if an attribute occurs in both the command-line arguments and the tag, and the values match. An
`attribute mismatch' happens if an attribute occurs in both the command-line arguments and the tag, but the values do not match.
Spans between <?xmlif if?> or <?xmlif elif?> and the next conditional processing instruction at the same nesting level are passed through
unaltered if there is at least one attribute match and no attribute mismatch; spans between <?xmlif if not?> and <?xmlif elif not?> and the
next conditional processing instruction are passed otherwise. Spans between <?xmlif else?> and the next conditional-processing tag are
passed through only if no previous span at the same level has been passed through. <?xmlif if?> and <?xmlif fi?> (and their `not'
variants) change the current nesting level; <?xmlif else?> and <?xmlif elif?> do not.
All these processing instructions will be removed from the output produced. Aside from the conditionalization, all other input is passed
through untouched; in particular, entity references are not resolved.
Value matching is by string equality, except that "|" in an attribute value is interpreted as an alternation character. Thus, saying
foo='red|blue' on the command line enables conditions red and blue. Saying color='black|white' in a tag matches command-line conditions
color='black' and color='white'.
Here is an example:
Always issue this text.
<?xmlif if condition='html'?>
Issue this text if 'condition=html' is given on the command line.
<?xmlif elif condition='pdf|ps'?>
Issue this text if 'condition=pdf' or 'condition=ps'
is given on the command line.
<?xmlif else?>
Otherwise issue this text.
<?xmlif fi?>
Always issue this text.
AUTHOR
Eric S. Raymond <esr@snark.thyrsus.com>
Author of xmlif program
Linux April 2009 XMLIF(1)
Check Out this Related Man Page
UNIFDEF(1) BSD General Commands Manual UNIFDEF(1)NAME
unifdef, unifdefall -- remove preprocessor conditionals from code
SYNOPSIS
unifdef [-ceklst] [-Ipath] [-Dsym[=val]] [-Usym] [-iDsym[=val]] [-iUsym] ... [-o output] [file]
unifdefall [-Ipath] ... file
DESCRIPTION
The unifdef utility selectively processes conditional cpp(1) directives. It removes from a file both the directives and any additional text
that they specify should be removed, while otherwise leaving the file alone.
The unifdef utility acts on #if, #ifdef, #ifndef, #elif, #else, and #endif lines, and it understands only the commonly-used subset of the
expression syntax for #if and #elif lines. It handles integer values of symbols defined on the command line, the defined() operator applied
to symbols defined or undefined on the command line, the operators !, <, >, <=, >=, ==, !=, &&, ||, and parenthesized expressions. Anything
that it does not understand is passed through unharmed. It only processes #ifdef and #ifndef directives if the symbol is specified on the
command line, otherwise they are also passed through unchanged. By default, it ignores #if and #elif lines with constant expressions, or
they may be processed by specifying the -k flag on the command line.
The unifdef utility also understands just enough about C to know when one of the directives is inactive because it is inside a comment, or
affected by a backslash-continued line. It spots unusually-formatted preprocessor directives and knows when the layout is too odd to handle.
A script called unifdefall can be used to remove all conditional cpp(1) directives from a file. It uses unifdef -s and cpp -dM to get lists
of all the controlling symbols and their definitions (or lack thereof), then invokes unifdef with appropriate arguments to process the file.
Available options:
-Dsym[=val]
Specify that a symbol is defined, and optionally specify what value to give it for the purpose of handling #if and #elif directives.
-Usym Specify that a symbol is undefined. If the same symbol appears in more than one argument, the last occurrence dominates.
-c If the -c flag is specified, then the operation of unifdef is complemented, i.e., the lines that would have been removed or blanked
are retained and vice versa.
-e Because unifdef processes its input one line at a time, it cannot remove preprocessor directives that span more than one line. The
most common example of this is a directive with a multi-line comment hanging off its right hand end. By default, if unifdef has to
process such a directive, it will complain that the line is too obfuscated. The -e option changes the behaviour so that, where pos-
sible, such lines are left unprocessed instead of reporting an error.
-k Process #if and #elif lines with constant expressions. By default, sections controlled by such lines are passed through unchanged
because they typically start ``#if 0'' and are used as a kind of comment to sketch out future or past development. It would be rude
to strip them out, just as it would be for normal comments.
-l Replace removed lines with blank lines instead of deleting them.
-o output
The argument given is the name of an output file to be used instead of the standard output. This file can be the same as the input
file.
-s Instead of processing the input file as usual, this option causes unifdef to produce a list of symbols that appear in expressions
that unifdef understands. It is useful in conjunction with the -dM option of cpp(1) for creating unifdef command lines.
-t Disables parsing for C comments and line continuations, which is useful for plain text.
-iDsym[=val]
-iUsym Ignore #ifdefs. If your C code uses #ifdefs to delimit non-C lines, such as comments or code which is under construction, then you
must tell unifdef which symbols are used for that purpose so that it will not try to parse comments and line continuations inside
those #ifdefs. One specifies ignored symbols with -iDsym[=val] and -iUsym similar to -Dsym[=val] and -Usym above.
-Ipath Specifies to unifdefall an additional place to look for #include files. This option is ignored by unifdef for compatibility with
cpp(1) and to simplify the implementation of unifdefall.
The unifdef utility copies its output to stdout and will take its input from stdin if no file argument is given.
The unifdef utility works nicely with the -Dsym option of diff(1).
DIAGNOSTICS
Too many levels of nesting.
Inappropriate #elif, #else or #endif.
Obfuscated preprocessor control line.
Premature EOF (with the line number of the most recent unterminated #if).
EOF in comment.
The unifdef utility exits 0 if the output is an exact copy of the input, 1 if not, and 2 if in trouble.
SEE ALSO cpp(1), diff(1)HISTORY
The unifdef command appeared in 4.3BSD. ANSI C support was added in FreeBSD 4.7.
BUGS
Expression evaluation is very limited.
Preprocessor control lines split across more than one physical line (because of comments or backslash-newline) cannot be handled in every
situation.
Trigraphs are not recognized.
There is no support for symbols with different definitions at different points in the source file.
The text-mode and ignore functionality does not correspond to modern cpp(1) behaviour.
BSD June 5, 2009 BSD