Re: fix in --help output - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: fix in --help output
Date
Msg-id 47BDEDBD.6020303@dunslane.net
Whole thread Raw
In response to Re: fix in --help output  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
Responses Re: fix in --help output  (Zdenek Kotala <Zdenek.Kotala@Sun.COM>)
List pgsql-patches

Zdenek Kotala wrote:
> Tom Lane napsal(a):
>> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>>> I attach fix for --help output. I replaced --NAME... with -NAME and
>>> add some example. getopt parse -- as a end of options and rest of
>>> line is not parsed.
>>
>> Surely this is outright wrong.  Or if you do have a getopt that acts
>> that way, the bug is that we are using it rather than one that acts
>> the way we want.
>
> Ah, sorry it really does not work.
>
> However, I get following error on Solaris:
>
> bash-3.2$ /usr/postgres/8.2/bin/postgres -D /tmp/db --share_buffers=16000
> /usr/postgres/8.2/bin/postgres: illegal option -- share_buffers=16000
> Try "postgres --help" for more information.
>
> but following command works fine:
>
> /usr/postgres/8.2/bin/postgres -D /tmp/db -c shared_buffers=16000
>
>
> By my opinion problem is in getopt which interprets -- as a end of
> options list.
>
> See
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02
>
> Guideline 10
>
> It maybe work on linux but I think it is not portable solution.
>
>
>

-- on its own might indicate the end of arguments, but that's quite
different from --foo=bar. Guideline 10 of the above surely only refers
to -- as an entire argument, not to -- as the first two characters of an
argument. If your getopt treats *any* -- as the end of options then I
think it is broken (complain to your vendor ;-) ). And the answer is
known - use the one we have in src/port.

cheers

andrew

pgsql-patches by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: fix in --help output
Next
From: Zdenek Kotala
Date:
Subject: Re: fix in --help output