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.

1. POSIX-compliant short (flag) option processing.

2. GNU-style long options processing. Long options are recognized without case sensitivity, and they may be abbreviated.

3. Environment variable initializations.

4. Initialization from RC or INI files, and saving the option state back into one.

5. INI files may be partitioned. One INI file may be used by several programs by partitioning it with lines containing, "[PROGRAM_NAME]", See section loading rc files.

6. Options may be marked as dis-abled with a disablement prefix. Such options may default to either an enabled or a disabled state. You may also provide an enablement prifix, too, e.g., --allow-mumble and --prevent-mumble.

7. Verify that required options are present between the minimum and maximum number of times on the command line.

8. 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.

9. Provides a callable routine to parse a text string as if it were from one of the RC/INI files.

10. --help and --version are automatically supported. --more-help will page the generated help.

11. 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.

12. 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.

13. If test-main is defined, the output `.c' file will contain a main routine that will be compiled when TEST_<prog-name>_OPTS is defined. See section 7.7 AutoOpts for Shell Scripts. If you choose to compile this program, it is currently capable of producing one of three results:
    1. A program that processes the arguments and writes to standard out portable shell commands containing the digested options.

    2. 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.

    3. test-main may specify a routine that will be called with a pointer to the option descriptions as the single argument. You must supply this routine and, obviously, you can cause it to do whatever you wish it to do.

14. 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.

15. 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-usage attribute (see section 7.3.3 Program Information Attributes). This can be overridden by the user himself with the AUTOOPTS_USAGE environment variable. If it exists and is set to the string gnu, it will force GNU-ish style format; if it is set to the string autoopts, it will force AutoOpts standard format; otherwise, it will have no effect.

Explanatory details: