> Peter Eisentraut <peter_e@gmx.net> writes:
> > No it's not, unfortunately. BSD versions of getopt, including the one we
> > ship as replacement, have a bug that considers any argument that starts
> > with '--' to be equivalent with '--' (which means end of options).
>
> Ugh. Nonetheless, that doesn't equate to "you need GNU getopt to use
> this". Can we be more specific about whether it works or not?
OK, I just checked BSD/OS, and see in the docs:
The getopt() function returns -1 when the argument list is exhausted, or a non-recognized option is encountered. The
interpretationof options in the argument list may be cancelled by the option `--' (double dash) which causes getopt()
tosignal the end of argument processing and returns -1. When all options have been processed (i.e., up to the first
non-optionargument), getopt() returns -1.
However, I also see:
Option arguments are allowed to begin with ``-''; this is reasonable but reduces the amount of error checking
possible.
I see in postmaster.c:
while ((opt = getopt(argc, argv, "A:a:B:b:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) !=
^
And I started the postmaster using:
./bin/postmaster -B 2000 -i $DEBUG --sort-mem=60
so while the documentation says "--" ends arguments, it appears if you
specify "-" to getopt, it will honor it and not end the argument list.
Because this is identical on BSD/OS and FreeBSD, I assume all the BSD's
are the same. Peter, was there a specific failure of "--" options that
you remember?
I will be glad to put the docs back to warning about "--" options if is
indeed true, or perhaps we can be more specific.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
