docs/184550: bc -q option not documented in man page

[Xin Li]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/6/13, 11:11 PM, Eitan Adler wrote:
> On Sat, Dec 7, 2013 at 2:09 AM, Xin Li <delphij at delphij.net>
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>> 
>> On 12/6/13, 10:48 PM, Eitan Adler wrote:
>>> On Sat, Dec 7, 2013 at 1:44 AM, Xin Li <delphij at delphij.net> 
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>>> 
>>>> On 12/6/13, 6:12 PM, Eitan Adler wrote:
>>>>> On 12/6/13, delphij at freebsd.org <delphij at freebsd.org>
>>>>> wrote:
>>>>>> Synopsis: bc -q option not documented in man page
>>>>>> 
>>>>>> State-Changed-From-To: open->closed State-Changed-By: 
>>>>>> delphij State-Changed-When: Sat Dec 7 01:06:05 UTC 2013 
>>>>>> State-Changed-Why: This is intentional.  Won't fix.
>>>>>> 
>>>>>> 
>>>>>> Responsible-Changed-From-To: freebsd-doc->delphij 
>>>>>> Responsible-Changed-By: delphij Responsible-Changed-When:
>>>>>> Sat Dec 7 01:06:05 UTC 2013 Responsible-Changed-Why:
>>>>>> Take.
>>>>>> 
>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=184550 
>>>>>> _______________________________________________ 
>>>>>> freebsd-doc at freebsd.org mailing list 
>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-doc To 
>>>>>> unsubscribe, send any mail to 
>>>>>> "freebsd-doc-unsubscribe at freebsd.org"
>>>>>> 
>>>>> 
>>>>> all options should be documented.  An undocumented option
>>>>> is a bug. If we don't want people using it we should
>>>>> document as such.
>>>> 
>>>> Well, no, it's not an undocumented option but a bug-for-bug 
>>>> compatibility shim.
>>> 
>>> Eh?
>>> 
>>>> However as Warren pointed out, it's a bug having it in
>>>> synopsis and usage.
>>> 
>>> It is not a bug.
>>> 
>>>> This is fixed in r259058.
>>> 
>>> This is a bug.
>>> 
>>>> With our limited manpower, I think it's more important to
>>>> improve our documentation in the direction that we describe
>>>> our stuff better, like how to write a vt(4) driver, etc.
>>> 
>>> I agree that we need better documentation for our own
>>> features; however, this is not a dichotomy.
>>> 
>>>> rather than documenting the bug-for-bug features which would
>>>> just give the reader an impression like "I can write program
>>>> according to GNU command line standard and expect the BSD
>>>> people to diligently implement bug-for-bug compatibility".
>>> 
>>> A similar discussion occurred when we implemented '==' for 
>>> test(1). If a program accepts some flag as input, or some text
>>> as input, it must be documented.  We may document it as a 
>>> non-portable, to be avoided feature, but it should not be left 
>>> alone.
>> 
>> Fair enough, how about this?
> 
> Works for me.  Thank you very much!

Ok, committed as 259060 and thanks for your patience.

Cheers,

-----BEGIN PGP SIGNATURE-----

iQIbBAEBCgAGBQJSosqEAAoJEJW2GBstM+nsneIP+ND+hIQUUFP6ndKvJqvBvqst
gOLdX/hLA98Z8htPv4CIY/gz5UCVdatP8gtDRXgu/RE6QV3ZEMJz1pGLd16ZN+y5
SsCckwYNIibzt4zj3X1Yx+yKIf9FI80r6X2fGAh6LlyISI86QNCeFs5BU6ycXyMp
FOhDDrJ0byoelly1kjAZiECuEwr+WcxtR7aSn4So7HT0/efzl16oSyb+lmyDdx+8
un88cFlArtpbn0MuQ390LE6LEEbQh8pvOh5dzR1yNgdn+bNkjnIUYrxc8sb7PAJ4
VZ+06KEojLThiVcvVdKJpm6MHEJZ6fJOeOevXm1kjpchbzTVAaFBpX/emkP7XR2t
Nfj5MxmmMEFpjWMmYslAq9VZgQwDKxP6CR2Y8Cv7FVICCse1FAnmd5TSVxK4zM5H
W5bzFBfLQTVX8P5PV2Bjc4Jz5SHeIQgfLcE2eLwNXe5MASC6eBLToK93BDCdGYxH
8GY2aIlJfVUbbLG0BY3pYGGGa0i77Fh00+qGQb/rguteYrCqCF1908a62M56GiOR
rW6KqLSSu7Uv9lIKavp9ngLNwI4D7qAXz2J3U0lUclZ10lbsAA6EvFDAdi9hQ/Py
XafPAvdRg+IkdYZLp0Ll0NZJzOJsRp/mTIkUalzfOEYsy0DGC/G9qHIbDOZmsZHo
DzIiN1lXnjXdEXZgeUw=
=/eYz
-----END PGP SIGNATURE-----