Fork: 0
tundra / tconfpy
Browse code
Misc. edits and cleanups.
master
1 parent 9ecab75 commit 9c17c98fef4a86b7ba1a892477a3526442f242d5
@tundra tundra authored on 24 Apr 2004
Patch
Unified Split
Showing 1 changed file
View
78
■■■■■
 tconfpy.3
returned to the calling program. However, they are treated as strings
during the parsing of the configuration file whenever they are used in
a comparison test or in a substitution.
 
 
.IP \(bu 4
Text inside a literal block (see section below on the
\fC.literal\fP directive) is left untouched. Whitespace,
the \fC#\fP symbol, and so on are not intepreted in any
way and are passed back to the calling program as-is. The
once exception to this rule is when variable substitution
inside literal blocks is enabled. This is discussed in a later
section of this document as well.
 
.IP \(bu 4
Any line which does not conform to these rules and/or is not
in the proper format for one of the operations described below,
is considered an error.
 
.ft C \" Courier
.nf
.ifany $MYPROGOPTIONS
options = $MYPROGOPTIONS
options = [$MYPROGOPTIONS]
 
.else
options = -b20 -c23 -z -r
 
.endif
.fi
.ft \" revert
 
Finally, you can use variable references here to get the name of a varible
to test by "indirection" (as we saw in the previous section on
accessing/setting variables indirectly0. This is not a recommended
way of doing things because it can be kind of obscure to understand,
Finally, you can use variable references here to get the name of a
variable to test by "indirection" (as we saw in the previous section
on accessing/setting variables indirectly. This should be used
sparingly since it can be kind of hard to understand after-the-fact,
but it is possible to do this:
 
.ft C \" Courier
.nf
.fi
.ft \" revert
 
This will test to see if either the variable \fCMyVarName\fP exists.
You can also do indirection through an environment variable, but
this is
.B really
not recommended because of the obscurity it introduces into a
configuration file. Say the \fCTERM\fP environment variable is set to
\fCvt100\fP:
 
You can also do indirection through an environment variable. Use this
construct with restraint - it can introduce serious obscurity into
your configuration file. Still, it has a place. Say the \fCTERM\fP
environment variable is set to \fCvt100\fP:
 
.ft C \" Courier
.nf
.ifany [$TERM]
.fi
.ft \" revert
 
This will test to see if a variable called \fCvt100\fP exists in the
symbol table. This is, perhaps, not the clearest possible construct!
symbol table. This is a handy way to see if you have a local variable
defined appropriate for the currently defined terminal, for instance.
 
.SS Comparison Conditional Directives
 
when used in combination with \*(TC conditional features:
 
.ft C \" Courier
.nf
.if [.OSTYPE] == posix
.literal
We're Running On A Unix-Like System
.endliteral
 
.else
.literal
We're Not Running On A Unix-Like System
.endliteral
 
.endif
.if [.PLATFORM] == posix
.literal
We're Running On A Unix-Like System
.endliteral
 
.else
.literal
We're Not Running On A Unix-Like System
.endliteral
 
.endif
.fi
.ft \" revert
 
 
 
# Now embed the greeting in a C program
.literal
 
[HASH]include <stdio.h>
#include <stdio.h>
 
main()
{
printf("[Greeting]");
 
If the calling program sets \fCLiteralVars=True\fP, the literal block
will return a C program that prints the greeting defined at the top of
this example. If they use the default \fCLiteralVars=False\fP, the C
program would print \fC[Greeting]\fP. (Well ... it should do that, but if
variable substitution is not enabled, the \fC[HASH]\fP reference will
not be resolved and the C program returned will be incorrect.)
program would print \fC[Greeting]\fP.
 
In other words, it is possible to have your literal blocks make
reference to other configuration variables (and Predefined or
Environment Variables). This makes it convenient to
.B and
other, arbitrary textual information that the program may need,
all in a single configuration file.
 
Notice too that the \fC#\fP character can be freely included within a
literal block. You don't have to use a Reserved Variable reference
like \fC[HASH]\fP here because
.B everything
(including whitespace) inside a literal block is left untouched.
 
If you fail to provide a terminating \fC.endliteral\fP, the program will
treat everthing as literal until it reaches the end of the
configuration file. This will generate an appropriate warning, but
will work as you might expect. Everything from the \fC.literal\fP
.fi
.ft \" revert
 
But this will not work. \*(TC is very strict about requiring you to
explicity distinguish between
explicitly distinguish between
.B variable names
and
.B variable references.
 
Now you're comparing the
.B value
of the variable \fCfoo\fP with the string \fCbar\fP.
 
This was done for a very good reason. By requiring the user
explicitly note whether they want the name or value of a variable
This was done for a very good reason. Because you have to
explicitly note whether you want the name or value of a variable
(instead of inferring it from context), you can mix both literal text
and variable values on either side of a comparison or assignment:
 
.ft C \" Courier