Re: Call for objections: deprecate postmaster -o switch?

> 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