7.1 AutoOpts Features 
AutoOpts supports option processing; option state saving; and
program documentation with innumerable features.  Here, we list
a few obvious ones and some important ones, but the full list is
really defined by all the attributes defined in the 7.3 Option Definitions
section.
- 
POSIX-compliant short (flag) option processing.
 
- 
GNU-style long options processing.  Long options
are recognized without case sensitivity, and they may be abbreviated.
 
- 
Environment variable initializations, See section 7.8.3 environment variable presets.
 
- 
Initialization from RC or INI files, and
saving the option state back into one, See section 7.8.1 RC or INI file presets.
 
- 
INI files may be partitioned.  One INI file may be used by several
programs by partitioning it with lines containing,
"[PROGRAM_NAME]", See section 7.8.1 RC or INI file presets.
 
- 
Options may be marked as dis-abledwith a disablement prefix.
Such options may default to either an enabled or a disabled state.  You
may also provide an enablement prefix, too, e.g.,--allow-mumbleand--prevent-mumble.
 
- 
Verify that required options are present between the minimum and
maximum number of times on the command line.
 
- 
Verify that conflicting options do not appear together, and that options
that require the presence of other options are, in fact, used in the
presence of other options.
 
- 
Provides a callable routine to parse
a text string as if it were from one of the RC/INI files.
 
- 
--helpand--versionare automatically supported.--more-helpwill page the generated help.
 
- 
By adding a `doc' and `arg-name' attributes to each option,
AutoGen will also be able to produce a man page and the `invoking'
section of a texinfo document.
 
- 
Insert the option processing state into Scheme-defined variables.
Thus, Guile based applications that are linked with private
main()routines can take advantage of all of AutoOpts' functionality.
 
- 
Various forms of main procedures can be added to the output,
See section 7.6 Generating main procedures.  There are four basic forms:
 
- 
A program that processes the arguments and writes to standard out
portable shell commands containing the digested options.
 
- 
A program that will generate portable shell commands to parse the defined
options.  The expectation is that this result will be copied into a
shell script and used there.
 
- 
A "for-each" main that will invoke a named function once for either
each non-option argument on the command line or, if there are none,
then once for each non-blank, non-comment input line read from stdin.
 
- 
A main procedure of your own design.  Its code can be supplied in the
option description template or by incorporating another template.
 
 
- 
Library suppliers can specify command line options that their
client programs will accept.  They specify option definitions
that get #include-d into the client option definitions
and they specify an "anchor" option that has a callback and must be invoked.
That will give the library access to the option state for their options.
 
- 
The generated usage text can be emitted in either AutoOpts standard
format (maximizing the information about each option), or GNU-ish
normal form.  The default form is selected by either specifying or not
specifying the gnu-usageattribute (see section 7.3.3 Program Information Attributes).
This can be overridden by the user himself with theAUTOOPTS_USAGEenvironment variable.  If it exists and is set
to the stringgnu, it will force GNU-ish style format; if it is
set to the stringautoopts, it will force AutoOpts standard
format; otherwise, it will have no effect.
 
- 
If you compile with ENABLE_NLSdefined and_()defined to
a localization function such asgettext(3GNU), then the option
processing code will be localizable (see section 7.13 Internationalizing AutoOpts).
  
This document was generated
by Bruce Korb on October 18, 2004 using texi2html
 
  