Обсуждение: unrecognized option '--help
From the list of nonsensical error messages: createdb: unrecognized option '--help' Try "createdb --help" for more information. createuser: unrecognized option '--help' Try "createuser --help" for more information. Explanation: If anything is ahead of --help, "--help" is then an unrecognized option. But the error message is still nonsensical, absurd and in the end, not very helpful. //D.S.
Hi, Which version/OS is this? I cannot reproduce it on my machine. Regards, Devrim On Thu, 2015-05-21 at 09:35 +0200, D. S. wrote: > From the list of nonsensical error messages: > > createdb: unrecognized option '--help' > Try "createdb --help" for more information. > > createuser: unrecognized option '--help' > Try "createuser --help" for more information. > > > Explanation: > If anything is ahead of --help, "--help" is then an unrecognized > option. > > But the error message is still nonsensical, absurd and in the end, not > very helpful. > > > //D.S. > > > -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
rpm -qf `which createdb` postgresql-9.3.6-1.fc21.x86_64 % createdb foo --help createdb: unrecognized option '--help' Try "createdb --help" for more information. % lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:d= esktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarc= h:printing-4.1-amd64:printing-4.1-noarch Distributor ID: Fedora Description: Fedora release 21 (Twenty One) Release: 21 Codename: TwentyOne On Thu, May 21, 2015 at 3:27 PM, Devrim G=C3=BCnd=C3=BCz <devrim@gunduz.org= > wrote: > > Hi, > > Which version/OS is this? I cannot reproduce it on my machine. > > Regards, Devrim > > On Thu, 2015-05-21 at 09:35 +0200, D. S. wrote: >> From the list of nonsensical error messages: >> >> createdb: unrecognized option '--help' >> Try "createdb --help" for more information. >> >> createuser: unrecognized option '--help' >> Try "createuser --help" for more information. >> >> >> Explanation: >> If anything is ahead of --help, "--help" is then an unrecognized >> option. >> >> But the error message is still nonsensical, absurd and in the end, not >> very helpful. >> >> >> //D.S. >> >> >> > > > -- > Devrim G=C3=9CND=C3=9CZ > Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com > PostgreSQL Dan=C4=B1=C5=9Fman=C4=B1/Consultant, Red Hat Certified Enginee= r > Twitter: @DevrimGunduz , @DevrimGunduzTR >
On Thu, May 21, 2015 at 4:35 PM, D. S. <spider@skuggor.se> wrote: > Explanation: > If anything is ahead of --help, "--help" is then an unrecognized > option. It is wanted this way for all the utilities of src/bin. See handle_help_version_opts() in src/bin/scripts/common.c for your case. > But the error message is still nonsensical, absurd and in the end, not > very helpful. Why? We could change handle_help_version_opts() to track the instances of --help/-? or --version/-V in the whole set of argc but: 1) This would change a behavior that has been like that for a long time 2) To which one should we give priority if both are specified 3) I am expecting someone else to show up and say that this is spec-compliant Still arguably that's a feature, not a bug. -- Michael
Michael Paquier wrote: > On Thu, May 21, 2015 at 4:35 PM, D. S. <spider@skuggor.se> wrote: > > Explanation: > > If anything is ahead of --help, "--help" is then an unrecognized > > option. > > It is wanted this way for all the utilities of src/bin. See > handle_help_version_opts() in src/bin/scripts/common.c for your case. Is it really wanted? I find it very annoying and wish it didn't do that. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2015-05-21 22:36:19 -0300, Alvaro Herrera wrote: > Michael Paquier wrote: > > On Thu, May 21, 2015 at 4:35 PM, D. S. <spider@skuggor.se> wrote: > > > Explanation: > > > If anything is ahead of --help, "--help" is then an unrecognized > > > option. > > > > It is wanted this way for all the utilities of src/bin. See > > handle_help_version_opts() in src/bin/scripts/common.c for your case. > > Is it really wanted? I find it very annoying and wish it didn't do > that. If I understand correctly it's a relic from the time when we couldn't rely on long options being supported. Since that's long past (we use our own getopt in that case), we imo should just rip out all that --help/-? specific code. I too find it *very* annoying. Andres
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Michael Paquier wrote:
>> It is wanted this way for all the utilities of src/bin. See
>> handle_help_version_opts() in src/bin/scripts/common.c for your case.
> Is it really wanted? I find it very annoying and wish it didn't do
> that.
I think the only thing that would do what you wanted would be to
recognize *any* argv element matching "--help" as a help request.
Maybe that's all right, but I'm a tad worried about the possibility
of false positives. Are we so sure that that string could never be
a database name, table name, etc?
regards, tom lane
On 2015-05-21 21:44:36 -0400, Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Michael Paquier wrote: > >> It is wanted this way for all the utilities of src/bin. See > >> handle_help_version_opts() in src/bin/scripts/common.c for your case. > > > Is it really wanted? I find it very annoying and wish it didn't do > > that. > > I think the only thing that would do what you wanted would be to > recognize *any* argv element matching "--help" as a help request. > Maybe that's all right, but I'm a tad worried about the possibility > of false positives. Are we so sure that that string could never be > a database name, table name, etc? I'm not following. Why does checking for --help/-? in the normal getopt_long call require that? In many, but not all, utilities only argv[1] is checked... Andres
Andres Freund <andres@anarazel.de> writes:
> On 2015-05-21 21:44:36 -0400, Tom Lane wrote:
>> I think the only thing that would do what you wanted would be to
>> recognize *any* argv element matching "--help" as a help request.
>> Maybe that's all right, but I'm a tad worried about the possibility
>> of false positives. Are we so sure that that string could never be
>> a database name, table name, etc?
> I'm not following. Why does checking for --help/-? in the normal
> getopt_long call require that? In many, but not all, utilities only
> argv[1] is checked...
As I recall, Alvaro's argument for this was "I typed multiple words of a
command and then want to check syntax, so I add --help to the end of what
I'd already typed and hit return, with the idea of recalling the command
and deleting the --help off the end so I don't have to retype what I
already entered."
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.
As I said, maybe that's okay. It'd certainly be 99.99% okay ... but
the other hundredth of a percent could be pretty painful.
regards, tom lane
Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Michael Paquier wrote: > >> It is wanted this way for all the utilities of src/bin. See > >> handle_help_version_opts() in src/bin/scripts/common.c for your case. > > > Is it really wanted? I find it very annoying and wish it didn't do > > that. > > I think the only thing that would do what you wanted would be to > recognize *any* argv element matching "--help" as a help request. > Maybe that's all right, but I'm a tad worried about the possibility > of false positives. Are we so sure that that string could never be > a database name, table name, etc? Hah. This reminds me of my time at the university when guys created files named "-fr" in other people's home directories to wreak havoc when the poor sods wanted to remove them. If you have a database called --help you should probably still be able to connect to it using any of: psql --dbname=--help psql -d --help psql -- --help I think it's perfectly reasonable to not recognize --help when it can be considered an argument to the previous option. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> If you have a database called --help you should probably still be able
> to connect to it using any of:
> psql --dbname=--help
> psql -d --help
> psql -- --help
> I think it's perfectly reasonable to not recognize --help when it can be
> considered an argument to the previous option.
But then you have the problem that --help will only work if you spelled
everything to its left correctly, or at least close enough that getopt
doesn't see a problem with it.
I did have an evil thought about this ... what about recognizing --help
as either the first or last argument, but not in between? That would
fix Alvaro's use-case, and for the 0.01% of cases where it's problematic,
I suspect it's always possible to rearrange the command so that the --help
argument doesn't have to be last.
regards, tom lane
On 2015-05-21 21:59:56 -0400, Tom Lane wrote: > As I recall, Alvaro's argument for this was "I typed multiple words of a > command and then want to check syntax, so I add --help to the end of what > I'd already typed and hit return, with the idea of recalling the command > and deleting the --help off the end so I don't have to retype what I > already entered." Something around that, yes. > 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. Sure, vacuumdb --dbname --help or something like that isn't going to work, but I think that's fairly minor in comparison to the above. And much easier to understand. > As I said, maybe that's okay. It'd certainly be 99.99% okay ... but > the other hundredth of a percent could be pretty painful. I can't see how treating it like the other options we already have could make it more painful? Greetings, Andres Freund
Andres Freund <andres@anarazel.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
Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > 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. Nah, I think that's okay for my usage. > 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. No objection to that, though I wonder (without looking at the code) if for binaries other than postmaster this is really worthwhile. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, May 22, 2015 at 11:24 AM, Tom Lane wrote: > 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. Well, this is true for postmaster and pg_ctl. By looking at pg_resetxlog, pg_rewind and initdb the root check occurs after option parsing. -- Michael
On Fri, May 22, 2015 at 12:59 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> 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. > > No objection to that, though I wonder (without looking at the code) if > for binaries other than postmaster this is really worthwhile. I would plead for consistency in this area, aka moving the root check before the option parsing for all the utilies, still check --help and --version are argv[1] (or argv[optind]), and move them as well in getopt_long parsing to get cleaner error messages be one of them mentioned. I can believe that some people may want to have quick looks at --help or --version even when running a binary utility as root even if it is not permitted to run under such circumstances. -- Michael