Your message dated Fri, 9 Mar 2012 12:05:17 -0800 (PST)
with message-id <[email protected]>
and subject line Re: Bug#662781: getopt.3 has a bad example, as is evident in
#655685 report
has caused the Debian Bug report #662781,
regarding getopt.3 has a bad example, as is evident in #655685 report
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
662781: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662781
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: manpages-dev
Version: 3.35-0.1
Severity: normal
Tags: patch
File: /usr/share/man/man3/getopt.3.gz
The following corrects a bad example in the manual page. It also
emphasizes the issue. See, for example, #655685, which was filed for
procps.
--- a/getopt.3 2012-03-06 11:33:58.252003620 +0200
+++ b/getopt.3 2012-03-06 11:33:36.000000000 +0200
@@ -371,14 +371,28 @@ has a technical error described in POSIX
The GNU
implementation (and probably all other implementations) implements the
correct behavior rather than that specified.
+.PP
+There should be no white space between a short option name
+and its possible arguments.
+That is, use
+.IR -unsecs
+, not
+.IR "-u nsecs" .
+With long options, use =, with no space characters either before or
+after it. That is,
+.IR --units=nsecs
+, nothing else.
.SH EXAMPLE
The following trivial example program uses
.BR getopt ()
to handle two program options:
.IR \-n ,
with no associated value; and
-.IR "\-t val" ,
+.IR "\-tval" ,
which expects an associated value.
+Note that
+.IR "\-t val" ,
+with a space, does not work.
.nf
.sp
#include <unistd.h>
--- End Message ---
--- Begin Message ---
--- On Wed, 3/7/12, Michael Kerrisk (man-pages) <[email protected]> wrote:
> I would say that it's a bit of a leap from reading that bug report to
> assume that the problem *must* be in getopt(3). I'd want to see a
> minimal test case demonstrating the behavior. And I assume the libc
> maintainers would want to see the same. In the meantime, I doubt that
> the problem is getopt(3), since then there would have been a rash of
> bug reports on this issue.
>
You are right. I am closing my report.
In fact, sysctl's actions on this matter are exactly as designed:
procps-3.3.2$ grep :: sysctl.c
getopt_long(argc, argv, "bneNwfp::qoxaAXr:Vdh", longopts,^M
procps-3.3.2$ grep -A4 "case 'p':" sysctl.c
case 'p':
preloadfileOpt = true;
if (optarg)
preloadfile = optarg;
break;
procps-3.3.2$ man 3 getopt | sed -n '/Two colons/,/GNU extension/p'
lowing argv-element, in optarg. Two colons mean an option
takes an optional arg; if there is text in the current argv-
element (i.e., in the same word as the option name itself, for
example, "-oarg"), then it is returned in optarg, otherwise
optarg is set to zero. This is a GNU extension. If optstring
procps-3.3.2$ man sysctl | grep -e '-p\[FILE]'
-p[FILE], --load[=FILE]
There is no space in -p[FILE] .
--- End Message ---
