Обсуждение: use of '=' in long options documentation
Looking at our ref pages, I see some manual pages specify long options
that take arguments using '=', e.g. initdb.sgml:
--long-opt=opt
and some do not, e.g. pg_dump.sgml:
--long-opt opt
So, which should we use, for consistency?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote: > Looking at our ref pages, I see some manual pages specify long options > that take arguments using '=', e.g. initdb.sgml: > > --long-opt=opt > > and some do not, e.g. pg_dump.sgml: > > --long-opt opt > > So, which should we use, for consistency? Using = is more common usage, I think.
Peter Eisentraut wrote: > On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote: > > Looking at our ref pages, I see some manual pages specify long options > > that take arguments using '=', e.g. initdb.sgml: > > > > --long-opt=opt > > > > and some do not, e.g. pg_dump.sgml: > > > > --long-opt opt > > > > So, which should we use, for consistency? > > Using = is more common usage, I think. Yeah! Someone chimed in with a vote! I will update the docs, but not adjust any summary that has a space after the equals, e.g. initdb. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> wrote: > Peter Eisentraut wrote: >> On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote: >>> Looking at our ref pages, I see some manual pages specify long >>> options that take arguments using '=', e.g. initdb.sgml: >>> >>> --long-opt=opt >>> >>> and some do not, e.g. pg_dump.sgml: >>> >>> --long-opt opt >>> >>> So, which should we use, for consistency? >> >> Using = is more common usage, I think. > > Yeah! Someone chimed in with a vote! I will update the docs, but > not adjust any summary that has a space after the equals, e.g. > initdb. I agree that using = is more common; but also that anything suggesting that a space after the = should be avoided. I think it's preferable to show the = when possible without misleading, and omit it when it would mislead. Accuracy should trump consistency here IMO. I think it's OK to omit in summary and show in detail. -Kevin
Kevin Grittner wrote: > Bruce Momjian <bruce@momjian.us> wrote: > > Peter Eisentraut wrote: > >> On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote: > >>> Looking at our ref pages, I see some manual pages specify long > >>> options that take arguments using '=', e.g. initdb.sgml: > >>> > >>> --long-opt=opt > >>> > >>> and some do not, e.g. pg_dump.sgml: > >>> > >>> --long-opt opt > >>> > >>> So, which should we use, for consistency? > >> > >> Using = is more common usage, I think. > > > > Yeah! Someone chimed in with a vote! I will update the docs, but > > not adjust any summary that has a space after the equals, e.g. > > initdb. > > I agree that using = is more common; but also that anything > suggesting that a space after the = should be avoided. I think it's > preferable to show the = when possible without misleading, and omit > it when it would mislead. Accuracy should trump consistency here > IMO. I think it's OK to omit in summary and show in detail. OK, agreed. I am working on a patch and will post it for review. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Applied. --------------------------------------------------------------------------- Bruce Momjian wrote: > Kevin Grittner wrote: > > Bruce Momjian <bruce@momjian.us> wrote: > > > Peter Eisentraut wrote: > > >> On tis, 2011-03-08 at 22:32 -0500, Bruce Momjian wrote: > > >>> Looking at our ref pages, I see some manual pages specify long > > >>> options that take arguments using '=', e.g. initdb.sgml: > > >>> > > >>> --long-opt=opt > > >>> > > >>> and some do not, e.g. pg_dump.sgml: > > >>> > > >>> --long-opt opt > > >>> > > >>> So, which should we use, for consistency? > > >> > > >> Using = is more common usage, I think. > > > > > > Yeah! Someone chimed in with a vote! I will update the docs, but > > > not adjust any summary that has a space after the equals, e.g. > > > initdb. > > > > I agree that using = is more common; but also that anything > > suggesting that a space after the = should be avoided. I think it's > > preferable to show the = when possible without misleading, and omit > > it when it would mislead. Accuracy should trump consistency here > > IMO. I think it's OK to omit in summary and show in detail. > > OK, agreed. I am working on a patch and will post it for review. > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > > -- > Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-docs -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +