src/port/getopt_long.c lossy with arguments having no option characters
Hi all,
The implementation of getopt_long in src/port has some limitations,
for example such commands do not work but they should:
$ createdb foobar3 -E win1252
createdb: too many command-line arguments (first is "win1252")
Try "createdb --help" for more information.
$ initdb pgdata --noclean
initdb: too many command-line arguments (first is "--noclean")
Try "initdb --help" for more information.
And those ones work:
createdb -E win1252 foobar3
initdb --noclean pgdata
I bumped into this problem when running the TAP tests on Windows, but
I guess that it easy to reproduce it with any builds of Postgres on
Windows as getopt_long is used unconditionally, on any version, for
all commands. Or on any platform that has not getopt_long, if any
exists.
Regards,
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Michael Paquier <michael.paquier@gmail.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, is not documented in any Postgres documentation,
and tends to have bad corner-case behaviors. I don't feel a need to make
our implementation replicate that.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 4/3/15 10:08 AM, Tom Lane wrote:
Michael Paquier <michael.paquier@gmail.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.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sat, Apr 4, 2015 at 4:47 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
On 4/3/15 10:08 AM, Tom Lane wrote:
Michael Paquier <michael.paquier@gmail.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Michael Paquier <michael.paquier@gmail.com> writes:
On Sat, Apr 4, 2015 at 4:47 AM, Peter Eisentraut <peter_e@gmx.net> wrote:
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.
If those tests are dependent on behavior we don't document as allowed,
I think we should change the tests. Want to send a patch?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Peter Eisentraut wrote:
On 4/3/15 10:08 AM, Tom Lane wrote:
Michael Paquier <michael.paquier@gmail.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.
The thing I hate the most about this issue is how some commands fail
with "--help: unrecognized option" or some such, when called as
command --foo=bar --baz --help
I am used to such calls to emit the help, then exit, and the command is
kept in history; that way, it's easy to adjust for the info found in the
help and edit later. As is, I tend to esc-# to save the commented-out
command in history, then call with only --help, then recall the
commented-out version.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 2015-04-03 19:06:38 -0300, Alvaro Herrera wrote:
The thing I hate the most about this issue is how some commands fail
with "--help: unrecognized option" or some such, when called ascommand --foo=bar --baz --help
I think that's primarily a different issue though. For some reason I
have yet to figure out --help is usually treated explicitly. E.g.:
if (argc > 1)
{
if (strcmp(argv[1], "--help") == 0 || strcmp(argv[1], "-?") == 0)
{
usage();
exit(0);
}
else if (strcmp(argv[1], "-V") == 0
|| strcmp(argv[1], "--version") == 0)
{
puts("pg_basebackup (PostgreSQL) " PG_VERSION);
exit(0);
}
}
while ((c = getopt_long(argc, argv, "D:F:r:RT:xX:l:zZ:d:c:h:p:U:s:wWvP",
long_options, &option_index)) != -1)
Some tools then copy the --help/-? handling to the normal option parsing
(like IIRC psql) but others don't (like pg_basebackup).
Greetings,
Andres Freund
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Sat, Apr 4, 2015 at 6:47 AM, Tom Lane wrote:
If those tests are dependent on behavior we don't document as allowed,
I think we should change the tests. Want to send a patch?
Attached are patches for HEAD and 9.4. There are problematic tests in
the ones of initdb, clusterdb, reindexdb and createdb.
--
Michael
Michael Paquier <michael.paquier@gmail.com> writes:
On Sat, Apr 4, 2015 at 6:47 AM, Tom Lane wrote:
If those tests are dependent on behavior we don't document as allowed,
I think we should change the tests. Want to send a patch?
Attached are patches for HEAD and 9.4. There are problematic tests in
the ones of initdb, clusterdb, reindexdb and createdb.
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 4/3/15 6:45 PM, Andres Freund wrote:
I think that's primarily a different issue though. For some reason I
have yet to figure out --help is usually treated explicitly.
Because at one point we did not have our own copy of getopt_long.c, so
long options might not have been available.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs