pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feeduse of '=' in long options documentation
6+ messages / 3 participants
[nested] [flat]
* use of '=' in long options documentation
@ 2011-03-09 03:32 Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Momjian @ 2011-03-09 03:32 UTC (permalink / raw)
To: pgsql-docs
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. +
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: use of '=' in long options documentation
@ 2011-03-09 15:44 Peter Eisentraut <peter_e@gmx.net>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 6+ messages in thread
From: Peter Eisentraut @ 2011-03-09 15:44 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-docs
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.
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: use of '=' in long options documentation
@ 2011-03-09 16:47 Bruce Momjian <bruce@momjian.us>
parent: Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Momjian @ 2011-03-09 16:47 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: pgsql-docs
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. +
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: use of '=' in long options documentation
@ 2011-03-09 16:55 Kevin Grittner <Kevin.Grittner@wicourts.gov>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 6+ messages in thread
From: Kevin Grittner @ 2011-03-09 16:55 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; Bruce Momjian <bruce@momjian.us>; +Cc: pgsql-docs
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
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: use of '=' in long options documentation
@ 2011-03-09 16:58 Bruce Momjian <bruce@momjian.us>
parent: Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Momjian @ 2011-03-09 16:58 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: Peter Eisentraut <peter_e@gmx.net>; pgsql-docs
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. +
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: use of '=' in long options documentation
@ 2011-03-10 14:10 Bruce Momjian <bruce@momjian.us>
parent: Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 6+ messages in thread
From: Bruce Momjian @ 2011-03-10 14:10 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; Peter Eisentraut <peter_e@gmx.net>; pgsql-docs
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. +
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2011-03-10 14:10 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2011-03-09 03:32 use of '=' in long options documentation Bruce Momjian <bruce@momjian.us>
2011-03-09 15:44 ` Peter Eisentraut <peter_e@gmx.net>
2011-03-09 16:47 ` Bruce Momjian <bruce@momjian.us>
2011-03-09 16:55 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2011-03-09 16:58 ` Bruce Momjian <bruce@momjian.us>
2011-03-10 14:10 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox