Re: unrecognized option '--help

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "D(dot) S(dot)" <spider(at)skuggor(dot)se>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: unrecognized option '--help
Date: 2015-05-22 02:24:57
Message-ID: 21331.1432261497@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2015-05-21 21:59:56 -0400, Tom Lane wrote:
>> This use-case is only going to work reliably if --help is recognized
>> regardless of what's in front of it. Otherwise, if you're right in
>> suspecting that you got something wrong, getopt parsing will fail
>> before it gets to your --help --- and what it will print is "please
>> use --help", which is exactly the symptom being complained of here.

> I don't think it really is the symptom complained about here. Right now
> "vacuumdb dbname --verbose" works (i.e. recognizes verbose as an
> option), whereas "vacuumdb dbname --help" doesn't. The latter is what's
> complained about here. And the reason for that is that
> --help/-?/--version/-v aren't part of the getopt_long() call.

Meh. I don't particularly object to including --help in the switch set
recognized in getopt_long ... but I doubt that that will actually fix
Alvaro's scenario.

Note that we should not rip out the existing code, because part of the
reason for that is that it acts before any of the other stuff that runs
before getopt parsing starts, eg the postmaster's refusal to run if you're
root.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2015-05-22 03:59:21 Re: unrecognized option '--help
Previous Message Andres Freund 2015-05-22 02:13:19 Re: unrecognized option '--help