| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
AutoOpts 35.0 is bundled with AutoGen. It is a tool that virtually eliminates the hassle of processing options and keeping man pages, info docs and usage text up to date. This package allows you to specify several program attributes, up to a hundred option types and many option attributes. From this, it then produces all the code necessary to parse and handle the command line and configuration file options, and the documentation that should go with your program as well.
All the features notwithstanding, some applications simply have well-established command line interfaces. Even still, those programs may use the configuration file parsing portion of the library. See the “AutoOpts Features” and “Configuration File Format” sections.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 Option Definitions section.
[PROGRAM_NAME]” or “<?program-name>”, See section configuration file presets.
<?auto-options [[option-text]]>” may be used to set AutoOpts
option processing options. Viz., GNU usage layout versus AutoOpts
conventional layout, and misuse-usage versus no-misuse-usage,
See section Usage and Version Info Display.
dis-abled with 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-mumble
and --prevent-mumble (see section Common Option Attributes).
xxx-value;” in
the option definition file. “xxx” is the name of the option below:
These are always available. “more-help” will pass the full usage
text through a pager.
This is added to the option list if “usage-opt” is specified.
It yields the abbreviated usage to ‘stdout’.
This is added to the option list if “version = xxx;” is specified.
These are added to the option list if “homerc” is specified.
gnu-usage attribute (see section 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.
ENABLE_NLS defined and _() defined to
a localization function such as gettext(3GNU), then the option
processing code will be localizable (see section Internationalizing AutoOpts).
allow-errors
(see section Program Description Attributes) attribute. When processing reaches a point
where optionProcess (see section optionProcess) needs to be called
again, the current option can be set with RESTART_OPT(n)
(see section RESTART_OPT( n ) - Resume Option Processing) before calling optionProcess.
See: See section Options for Library Code.
#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.
#include into their own option definitions.
See “AutoOpt-ed Library for AutoOpt-ed Program” (see section AutoOpt-ed Library for AutoOpt-ed Program)
for more details.
main() routines can take advantage of all of AutoOpts’ functionality.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When AutoGen is installed, the AutoOpts project is installed with it. AutoOpts includes various AutoGen templates and a pair of shared libraries. These libraries may be used under the terms of version 3 of the GNU Lesser General Public License (LGPL).
One of these libraries (libopts) is needed by programs that are built
using AutoOpts generated code. This library is available as a separate
“tear-off” source tarball. It is redistributable for use under either of
two licenses: The above mentioned GNU Lesser General Public License, and
the advertising-clause-free BSD license. Both of these license terms are
incorporated into appropriate COPYING files included with the libopts
source tarball. This source may be incorporated into your package with
the following simple commands:
rm -rf libopts libopts-* gunzip -c `autoopts-config libsrc` | \ tar -xvf - mv libopts-*.*.* libopts |
View the ‘libopts/README’ file for further integration information.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
AutoOpts has its conventional way of displaying option information that includes somewhat more information that the standard GNU method. AutoOpts will also print out a line of usage text for each option type when options are misspecified. GNU programs typically do not do this. These defaults can be changed on a per-program basis by adding either or both of the following in the option definition file:
gnu-usage; no-misuse-usage; |
Users may also override these settings with the AUTOOPTS_USAGE
environment variable. It may be set to a comma or white space separated
list of the following strings:
The format of the extended usage text will be displayed in GNU-normal form.
The default display for --version will be to include a note
on licensing terms.
The format of the extended usage will be in AutoOpts’ native layout.
When an option error is made on the command line, the abbreviated usage text will be suppressed.
When an option error is made on the command line, the abbreviated usage text will be shown.
The setting used is the last one seen. The autoopts and
misuse-usage serve no purpose, unless the definition file
entries were specified as above.
Note for developers:
The templates used to implement AutoOpts depend heavily upon
token pasting. That mens that if you name an option, “debug”, for
example, the generated header will expect to be able to emit
#define macros such as this:
#define DESC(n) (autogenOptions.pOptDesc[INDEX_OPT_## n]) |
and expect DESC(DEBUG) to expand correctly into
(autogenOptions.pOptDesc[INDEX_OPT_DEBUG]).
If DEBUG is #defined to something else, then
that something else will be in the above expansion.
If you discover you are having strange problems like this,
you may wish to use some variation of the guard-option-names
See section Program Description Attributes.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Since it is generally easier to start with a simple example than it is
to look at the options that AutoGen uses itself, here is a very simple
AutoOpts example. You can copy this example out of the Info file and
into a source file to try it. You can then embellish it into what you
really need. For more extensive examples, you can also examine the help
output and option definitions for the commands columns,
getdefs and autogen itself.
For our simple example, assume you have a program named check
that takes two options:
check does.
You want this option available as a POSIX-style flag option
and a GNU long option. You want to allow as many of these
as the user wishes.
First, specify your program attributes and its options to AutoOpts, as with the following example.
AutoGen Definitions options;
prog-name = check;
prog-title = "Checkout Automated Options";
long-opts;
main = { main-type = shell-process; };
flag = {
name = check-dirs;
value = L; /* flag style option character */
arg-type = string; /* option argument indication */
max = NOLIMIT; /* occurrence limit (none) */
stack-arg; /* save opt args in a stack */
descrip = "Checkout directory list";
};
flag = {
name = show_defs;
descrip = "Show the definition tree";
disable = dont; /* mark as enable/disable type */
/* option. Disable as `dont-' */
};
|
Then perform the following steps:
cflags="-DTEST_CHECK_OPTS `autoopts-config cflags`"
ldflags="`autoopts-config ldflags`"
autogen checkopt.def
cc -o check -g ${cflags} checkopt.c ${ldflags}
./check --help
Running those commands yields:
check - Checkout Automated Options
USAGE: check [ -<flag> [<val>] | --<name>[{=| }<val>] ]...
Flg Arg Option-Name Description
-L Str check-dirs Checkout directory list
- may appear multiple times
no show-defs Show the definition tree
- disabled as --dont-show-defs
-? no help Display extended usage information and exit
-! no more-help Extended usage information passed thru pager
Options are specified by doubled hyphens and their name or by a single
hyphen and the flag character.
|
Normally, however, you would compile ‘checkopt.c’ as in:
cc -o checkopt.o $cflags -c checkopt.c |
and link ‘checkopt.o’ with the rest of your program.
The main program causes the options to be processed
by calling optionProcess (see section optionProcess):
main( int argc, char** argv )
{
{
int optct = optionProcess( &checkOptions, argc, argv );
argc -= optct;
argv += optct;
}
|
The options are tested and used as in the following fragment.
“ENABLED_OPT” is used instead of “HAVE_OPT” for the
show-defs option because it is an enabled/disabled option type:
if ( ENABLED_OPT( SHOW_DEFS )
&& HAVE_OPT( CHECK_DIRS )) {
int dirct = STACKCT_OPT( CHECK_DIRS );
char** dirs = STACKLST_OPT( CHECK_DIRS );
while (dirct-- > 0) {
char* dir = *dirs++;
...
|
A lot of magic happens to make this happen. The rest of this chapter will describe the myriad of option attributes supported by AutoOpts. However, keep in mind that, in general, you won’t need much more than what was described in this "quick start" section.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
AutoOpts uses an AutoGen definitions file for the definitions of the program options and overall configuration attributes. The complete list of program and option attributes is quite extensive, so if you are reading to understand how to use AutoOpts, I recommend reading the "Quick Start" section (see section Quick Start) and paying attention to the following:
prog-name, prog-title, and argument, program
attributes, See section Program Description Attributes.
name and descrip option attributes, See section Required Attributes.
value (flag character) and min (occurrence counts)
option attributes, See section Common Option Attributes.
arg-type from the option argument specification section,
See section Option Argument Specification.
Keep in mind that the majority are rarely used and can be safely ignored. However, when you have special option processing requirements, the flexibility is there.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following global definitions are used to define attributes of the entire program. These generally alter the configuration or global behavior of the AutoOpts option parser. The first two are required of every program. The third is required if there are to be any left over arguments (operands) after option processing. The rest have been grouped below. Except as noted, there may be only one copy of each of these definitions:
This attribute is required. Variable names derived from this name
are derived using string->c_name! (see section ‘string->c-name!’ - map non-name chars to underscore).
This attribute is required and may be any descriptive text.
This attribute is required if your program uses operand arguments.
It specifies the syntax of the arguments that follow the options.
It may not be empty, but if it is not supplied, then option processing
must consume all the arguments. If it is supplied and starts with an
open bracket ([), then there is no requirement on the presence or
absence of command line arguments following the options. Lastly, if it
is supplied and does not start with an open bracket, then option
processing must not consume all of the command line arguments.
| 7.5.1.1 Usage and Version Info Display | ||
| 7.5.1.2 Program Configuration | ||
| 7.5.1.3 Programming Details | ||
| 7.5.1.4 User Presentation Attributes |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These will affect the way usage is seen and whether or not version information gets displayed.
If this attribute is provided, it may specify the full length usage text, or a variable name assignable to a “char const *” pointer, or it may be empty. The meanings are determined by the length.
This string should be readily translatable and provision will be made to translate it if this is provided and the source code is compiled with “ENABLE_NLS” defined.
If this attribute is provided, it is used to specify an abbreviated version of the usage text. This text is constructed in the same way as the “full-usage”, described above.
AutoOpts normaly displays usage text in a format that provides more
information than the standard GNU layout, but that also means it is
not the standard GNU layout. This attribute changes the default to
GNU layout, with the AUTOOPTS_USAGE environment variable used
to request autoopts layout.
See See section Developer and User Notes.
When there is a command line syntax error, by default AutoOpts will
display the abbreviated usage text, rather than just a one line
“you goofed it, ask for usage” message. You can change the default
behavior for your program by supplying this attribute. The user may
override this choice, again, with the AUTOOPTS_USAGE environment
variable. See See section Developer and User Notes.
The version text in the ‘getopt.tpl’ template will include this text in parentheses after the program name, when this attribute is specified. For example:
mumble (stumble) 1.0 |
says that the “mumble” program is version 1.0 and is part of the
“stumble” group of programs.
Specifies the program version and activates the VERSION option, See section Automatically Supported Options.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Programs may be “pre-configured” before normal command line options are processed (See see section Immediate Action Attributes). How configuration files and environment variables are handled get specified with these attributes.
Indicates that the command line usage of --load-opts and/or
--save-opts are disallowed.
Indicates looking in the environment for values of variables named,
PROGRAM_OPTNAME or PROGRAM, where PROGRAM is the
upper cased C-name of the program and OPTNAME is the
upper cased C-name of a specific option. The contents of
the PROGRAM variable, if found, are tokenized and processed.
The contents of PROGRAM_OPTNAME environment variables are taken
as the option argument to the option nameed optname.
Specifies either a directory or a file using a specific path, a path based
on an environment variable or a path relative to installation directories.
The method used depends on the first two characters of the name. If the
first character is not the dollar character ($), then it is
presumed to be a path name based on the current directory.
Otherwise, the method depends on the second character:
The path is relative to the directory where the executable was found.
The path is relative to the package data directory, e.g.
/usr/local/share/autogen.
The path is derived from the named environment variable.
Use as many as you like. The presence of this attribute
activates the --save-opts and --load-opts options.
See the optionMakePath(3AGEN) man page for excruciating details.
See section configuration file presets.
Specifies the configuration file name. This is only useful if you
have provided at least one homerc attribute.
default: .<prog-name>rc
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These attributes affect some of the ways that the option data are used and made available to the program.
The contents of this attribute should be just the name of the configuration file. A "#include" naming this file will be inserted at the top of the generated header.
These values should be defined as indexed values, thus:
exit-name[0] = success; exit-desc[0] = 'Successful program execution.'; exit-name[1] = failure; exit-desc[1] = 'The operation failed or command syntax was not valid.'; |
By default, all programs have these effectively defined for them.
They may be overridden by explicitly defining any or all of these values.
Additional names and descriptions may be defined.
They will cause an enumeration to be emitted, like this one
for getdefs:
typedef enum {
GETDEFS_EXIT_SUCCESS = 0,
GETDEFS_EXIT_FAILURE = 1
} getdefs_exit_code_t;
|
which will be augmented by any exit-name definitions beyond “1”.
This attribute will cause two procedures to be added to the code file:
usage_message and vusage_message, with any applicable prefix
(see prefix, below). They are declared in the
generated header, thus:
extern void vusage_message(char const * fmt, va_list ap); extern void usage_message(char const * fmt, ...); |
These functions print the message to ‘stderr’ and invoke the usage
function with the exit code set to 1 (EXIT_FAILURE).
This string is inserted into the .h interface file. Generally used for
global variables or #include directives required by
flag-code text and shared with other program text.
Do not specify your configuration header (‘config.h’) in this
attribute or the include attribute, however. Instead, use
config-header, above.
AutoOpts generates macros that presume that there are no cpp macros
with the same name as the option name. For example, if you have an option
named, debug, then you must not use #ifdef DEBUG in your code.
If you specify this attribute, every option name will be guarded. If the name
is #define-d, then a warning will be issued and the name undefined.
If you do not specify this and there is a conflict, you will get strange
error messages.
This attribute may be set to any of four recognized states:
#undef) any conflicting preprocessor macros. The code
will include compiler warnings (via #warning). Some compilers are
not ANSI-C-99 compliant yet and will error out on those warnings. You may
compile with -DNO_OPTION_NAME_WARNINGS to silence or mostly silence
them.
no-warning”. All of the needed
#undefs will be emitted, without any conflict checking #warning
directives emitted.
full-enum”. The option manipulation
preprocessor macros will not token paste the option names to the index
enumeration prefix. e.g. you will need to use HAVE_OPT(INDEX_OPT_DEBUG)
instead of HAVE_OPT(DEBUG).
This string is inserted into the .c file. Generally used for global
variables required only by flag-code program text.
If you are going to handle your option processing with the getopt.tpl
template instead of using libopts, then specify this attribute. It will
suppress mention of --more-help in the generated documentation.
(getopt_long does not support --more-help.)
This value is inserted into all global names. This will disambiguate them if more than one set of options are to be compiled into a single program.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Attributes that affect the user’s experience.
The presence of this attribute indicates ignoring any command line
option errors. This may also be turned on and off by invoking the
macros ERRSKIP_OPTERR and ERRSTOP_OPTERR from the
generated interface file.
Presence indicates GNU-standard long option processing. Partial name matches are accepted, if they are at least two characters long and the partial match is unique. The matching is not case sensitive, and the underscore, hyphen and carat characters are all equivalent (they match).
If any options do not have an option value (flag character) specified,
and least one does specify such a value, then you must specify
long-opts. If none of your options specify an option value
(flag character) and you do not specify long-opts, then command
line arguments are processed in "named option mode". This means that:
- and -- are completely optional.
argument program attribute is disallowed.
Modifies when or whether option names get translated. If provided, it must be assigned one of two values:
to suppress option name translation for configuration file and and environment variable processing.
to suppress option name translation completely. The usage text will
always be translated if ENABLE_NLS is defined and you have
translations for that text.
See also the various “XLAT” interface entries in the
AutoOpts Programmatic Interface section (see section Programmatic Interface).
Normally, POSIX compliant commands do not allow for options to be interleaved with operands. If this is necessary for historical reasons, there are two approaches available:
optionProcess to return the index of the operand like it normally
does and process the operand(s). When an operand is encountered that starts
with a hyphen, then set the AutoOpts current index with the RESTART_OPT
macro (see see section RESTART_OPT( n ) - Resume Option Processing), and re-invoke optionProcess. This will
also allow you to process the operands in context.
Specifies that the --reset-option command line option is to be supported.
This makes it possible to suppress any setting that might be found in
a configuration file or environment variable.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some libraries provide their own code for processing command line options, and this may be used by programs that utilize AutoOpts. You may also wish to write a library that gets configured with AutoOpts options and config files. Such a library may either supply its own configury routine and process its own options, or it may export its option descriptions to programs that also use AutoOpts. This section will describe how to do all of these different things.
| 7.5.2.1 AutoOpt-ed Library for AutoOpt-ed Program | ||
| 7.5.2.2 AutoOpt-ed Library for Regular Program | ||
| 7.5.2.3 AutoOpt-ed Program Calls Regular Library |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The library source code must provide an option definition file that consists
of only the attribute library
and flag entries. The “library” attribute does not need any
associated value, so it will generally appeary by itself on a line folowed
by a semi-colon. The first flag entry must contain the following
attributes:
This name is used in the construction of a global pointer of type
tOptDesc const*. It is always required.
It tells AutoOpts that this option serves no normal purpose.
It will be used to add usage clarity and to locate option descriptors
in the library code.
This is a string that is inserted in the extended usage display before the options specific to the current library. It is always required.
This should match the name of the library. This string is also used in the construction of the option descriptor pointer name. In the end, it looks like this:
extern tOptDesc const* <<lib-name>>_<<name>>_optDesc_p; |
and is used in the macros generated for the library’s .h file.
In order to compile this AutoOpts using library, you must create a
special header that is not used by the client program. This is accomplished
by creating an option definition file that contains essentially exactly the
following:
AutoGen definitions options; prog-name = does-not-matter; // but is always required prog-title = 'also does not matter'; // also required config-header = 'config.h'; // optional, but common library; #include library-options-only.def |
and nothing else. AutoGen will produce only the .h file.
You may now compile your library, referencing just this .h file.
The macros it creates will utilize a global variable that will be defined
by the AutoOpts-using client program. That program will need to
have the following #include in its option definition file:
#include library-options-only.def |
All the right things will magically happen so that the global variables
named <<lib-name>>_<<name>>_optDesc_p are initialized correctly.
For an example, please see the AutoOpts test script:
‘autoopts/test/library.test’.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In this case, your library must provide an option processing function
to a calling program. This is accomplished by setting the allow-errors
global option attribute. Each time your option handling function is called,
you must determine where your scan is to resume and tell the AutoOpts library
by invoking:
RESTART_OPT(next_arg_index); |
and then invoke not_opt_index = optionProcess(...).
The not_opt_index value can be used to set optind,
if that is the global being used to scan the program argument array.
In this method, do NOT utilize the global library attribute.
Your library must specify its options as if it were a complete program.
You may choose to specify an alternate usage() function so that
usage for other parts of the option interface may be displayed as well.
See “Program Information Attributes” (see section Program Information Attributes).
At the moment, there is no method for calling optionUsage() telling
it to produce just the information about the options and not the program
as a whole. Some later revision after somebody asks.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
As with providing an AutoOpt-ed library to a non-AutoOpt-ed
program, you must write the option description file as if you were writing
all the options for the program, but you should specify the
allow-errors global option attribute and you will likely want an
alternate usage() function (see “Program Information Attributes”
see section Program Information Attributes). In this case, though, when
optionProcess() returns, you need to test to see if there might be
library options. If there might be, then call the library’s exported
routine for handling command line options, set the next-option-to-process
with the RESTART_OPT() macro, and recall optionProcess().
Repeat until done.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These attributes are used to define how and what information is displayed to the user of the program.
The copyright is a structured value containing three to five
values. If copyright is used, then the first three are required.
An example of this might be:
copyright = {
date = "1992-2008";
owner = "Bruce Korb";
eaddr = 'bkorb@gnu.org';
type = GPL;
};
|
This string is added to the usage output when the HELP option is selected.
Gives additional information whenever the usage routine is invoked.
The name of the package the program belongs to. This will appear
parenthetically after the program name in the version and usage output,
e.g.: autogen (GNU autogen) - The Automated Program Generator.
This attribute will not change anything except appearance. Normally, the option names are all documented in lower case. However, if you specify this attribute, then they will display in the case used in their specification. Command line options will still be matched without case sensitivity.
These define global pointer variables that point to the program
descriptor and the first option descriptor for a library option. This
is intended for use by certain libraries that need command line and/or
initialization file option processing. These definitions have no effect
on the option template output, but are used for creating a library
interface file. Normally, the first "option" for a library will be a
documentation option that cannot be specified on the command line, but
is marked as settable. The library client program will invoke the
SET_OPTION macro which will invoke a handler function that will
finally set these global variables.
Optionally names the usage procedure, if the library routine
optionUsage() does not work for you. If you specify
my_usage as the value of this attribute, for example, you will
use a procedure by that name for displaying usage. Of course, you will
need to provide that procedure and it must conform to this profile:
void my_usage( tOptions* pOptions, int exitCode ) |
Normally, the default format produced by the optionUsage procedure
is AutoOpts Standard. By specifying this attribute, the default format
will be GNU-ish style. Either default may be overridden by the user with
the AUTOOPTS_USAGE environment variable. If it is set to gnu
or autoopts, it will alter the style appropriately. This attribute
will conflict with the usage attribute.
Some applications traditionally require that the command operands be
intermixed with the command options. In order to handle that, the arguments
must be reordered. If you are writing such an application, specify this
global option. All of the options (and any associated option arguments)
will be brought to the beginning of the argument list. New applications
should not use this feature, if at all possible. This feature is
disabled if POSIXLY_CORRECT is defined in the environment.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When AutoOpts generates the code to parse the command line options, it has
the ability to produce any of several types of main() procedures.
This is done by specifying a global structured value for
main. The values that it contains are dependent on the value set for
the one value it must have: main-type.
The recognized values for main-type are:
Here is an example of an include variation:
main = {
main-type = include;
tpl = "main-template.tpl";
};
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When the main-type is specified to be guile,
a main() procedure is generated that calls gh_enter(), providing
it with a generated inner_main() to invoke. If you must perform
certain tasks before calling gh_enter(), you may specify such code
in the value for the
before-guile-boot attribute.
The inner_main() procedure itself will process the command line
arguments (by calling optionProcess(),
see section optionProcess), and then either invoke the code
specified with the
guile-main attribute, or else export the parsed options to Guile
symbols and invoke the scm_shell() function from the Guile library.
This latter will render the program nearly identical to the stock
guile(1) program.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This will produce a main() procedure that parses the command line
options and emits to ‘stdout’ Bourne shell commands that puts the
option state into environment variables. This can be used within a
shell script as follows:
unset OPTION_CT
eval "`opt_parser \"$@\"`"
test -z "${OPTION_CT}" && exit 1
test ${OPTION_CT} -gt 0 && shift ${OPTION_CT}
|
If the option parsing code detects an error or a request for usage, it will not emit an assignment to OPTION_CT and the script should just exit. If the options are set consistently, then something along the lines of the following will be written to ‘stdout’ and evaled:
OPTION_CT=4
export OPTION_CT
MYPROG_SECOND='first'
export MYPROG_SECOND
MYPROG_ANOTHER=1 # 0x1
export MYPROG_ANOTHER
|
If the arguments are to be reordered, however, then the resulting set
of operands will be emitted and OPTION_CT gets set to zero.
For example, the following would be appended to the above:
set -- 'operand1' 'operand2' 'operand3'
OPTION_CT=0
|
OPTION_CT is set to zero since it is not necessary to shift
off any options.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This will produce a main() procedure that emits a shell script
that will parse the command line options. That script can be emitted
to ‘stdout’ or inserted or substituted into a pre-existing shell
script file. Improbable markers are used to identify previously inserted
parsing text:
# # # # # # # # # # -- do not modify this marker -- |
The program is also pretty insistent upon starting its parsing script on the second line.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must supply a value for the main-text attribute.
You may also supply a value for
option-code. If you do, then the optionProcess invocation
will not be emitted into the code. AutoOpts will wrap the main-text
inside of:
int
main( int argc, char** argv )
{
{ // replaced by option-code, if that exists
int ct = optionProcess( &<<prog-name>>Options, argc, argv );
argc -= ct;
argv += ct;
}
<<your main-text goes here>>
}
|
so you can most conveniently set the value with a “here string”
(see section A Here String):
code = <<- _EndOfMainProc_ <<your text goes here>> _EndOfMainProc_; |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the procedure is emitted as a static procedure in the generated code.
This procedure should return 0 on success, a cumulative error code on warning and exit without returning on an unrecoverable error. As the cumulative warning codes are or-ed together, the codes should be some sort of bit mask in order to be ultimately decipherable (if you need to do that).
If the called procedure needs to cause a fail-exit, it is expected to call
exit(3) directly. If you want to cause a warning exit code, then this
handler function should return a non-zero status. That value will be
OR-ed into a result integer for computing the final exit code. E.g.,
here is part of the emitted code:
int res = 0;
if (argc > 0) {
do {
res |= my_handler( *(argv++) );
} while (--argc > 0);
} else { ...
|
handler-typeIf you do not supply this attribute, your handler procedure must be the default type. The profile of the procedure must be:
int my_handler( char const *pz_entry ); |
However, if you do supply this attribute, you may set the value to any of four alternate flavors:
This is essentially the same as the default handler type, except that before your procedure is invoked, the generated code has verified that the string names an valign="dle" align="left">[ > ]
You must write a template to produce your main procedure.
You specify the name of the template with the tpl attribute
and it will be incorporated at the point where AutoOpts is ready
to emit the main() procedure.
This can be very useful if, in your working environment, you have
many programs with highly similar main() procedures. All you need
to do is parameterize the variations and specify which variant is needed
within the main AutoOpts specification. Since you are coding
the template for this, the attributes needed for this variation would
be dictated by your template.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You must write a template to produce your main procedure. That template
must contain a definition for the function specified with the func
attribute to this main() procedure specification. Typically, this
template will be incorporated by using the --lib-template option
(see section lib-template option (-l)) in the AutoGen invocation. Otherwise, this
variation operates in much the same way as “include”
(see section include: code emitted from included template) method.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This produces a main procedure that invokes a procedure once for each operand
on the command line (non-option arguments), OR once for each
non-blank, non-comment stdin input line. Leading and trailing white
space is trimmed from the input line and comment lines are lines that are
empty or begin with a comment character, defaulting to a hash (’#’) character.
NB:
The argument program attribute (see section Program Description Attributes)
must begin with the [ character, to indicate that there are
command operands, but that they are optional.
There are a number of attributes to main that may be used:
handler-procThis attribute is required. It is used to name the procedure to call. That procedure is presumed to be external, but if you provide the code for it, then the