Fix option processing from the library layer to address unexpected

behavior(s); e.g., `-Xd' versus `-dX' did not produce the same results.

The libraries common.subr and dialog.subr automatically process the
arguments passed to the program and enable/disable functionality without the
need to process the arguments within your program. For example, if "$@"
contains `-d', common.subr will see this and enable debugging regardless of
whether you process "$@" yourself or not (this automatic processing can
easily be disabled for custom scripts that don't want it; see the afore-
mentioned scripts for additional details).

NOTE: common.subr stores a copy of "$@" in $ARGV for convenient (and
repeated) processing by libraries such as dialog.subr which provide such
transparent functionality for the consuming script(s).

However, the libraries don't know if a program wants to accept `extra'
options. Flags are not really a problem, because the library can be
programmed to silently ignore unknown flags. The trouble comes into play
when the program wants to define an option that takes an argument.

For example:

	bsdconfig -D logfile -X

In the above example, the library uses getopts to process $ARGV and if it
doesn't know that `-D' takes an argument, the option processing will
prematurely terminate on `logfile' (this is standard/correct behavior for
getopts but is undesired in our situation where we have partially off-loaded
main argument processing).

The problem is solved by allowing the program to define an extra set of
options to be included in each library's handling of $ARGV. Only options
that require arguments are truly necessary to be pre-specified in this new
manner.

0 files changed, 0 insertions, 0 deletions