Re: src/port/getopt_long.c lossy with arguments having no option characters

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: src/port/getopt_long.c lossy with arguments having no option characters
Date: 2015-04-03 21:41:59
Message-ID: CAB7nPqSTsawDHgCVfLEtUpW7wMeu2sQXZDB5=5aOK-o+BBTc_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Apr 4, 2015 at 4:47 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 4/3/15 10:08 AM, Tom Lane wrote:
>> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>>> The implementation of getopt_long in src/port has some limitations,
>>> for example such commands do not work but they should:
>>
>> No, those should not work. You're too used to versions that don't insist
>> on switches-before-non-switch-arguments. Such behavior is an extension
>> that is not standard,
>
> It is true that options after non-option arguments are a GNU extension,
> but long options are also a GNU extension. So the behavior we provide
> is neither pure POSIX nor pure GNU. I can see how that would be confusing.

Well, OK. Then we had better update a bit the TAP tests of initdb and
createdb because they break on any platform which is not compliant
with that.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2015-04-03 21:47:31 Re: src/port/getopt_long.c lossy with arguments having no option characters
Previous Message David G. Johnston 2015-04-03 20:35:39 Re: BUG #12950: Update problem