Bug#662781: getopt.3 has a bad example, as is evident in #655685 report
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.0 +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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662781: getopt.3 has a bad example, as is evident in #655685 report
The following corrects a bad example in the manual page. It also emphasizes the issue. See, for example, #655685, which was filed for procps. Hi. Upstream maintainer of man-pages here. I'm not at all sure that the problem in #655685 is because of getopt(). (How did you conclude that it is?) Allowing a space between option character and argument is longstanding UNIX (and Linux behavior), and as far as I can see POSIX is explicit in allowing it--POSIX.1-2001 contains this text (note point 2): The getopt() function shall return the next option character (if one is found) from argv that matches a character in opt‐ string, if there is one that matches. If the option takes an argument, getopt() shall set the variable optarg to point to the option-argument as follows: 1. If the option was the last character in the string pointed to by an element of argv, then optarg shall contain the next element of argv, and optind shall be incremented by 2. If the resulting value of optind is greater than argc, this indicates a missing option-argument, and getopt() shall return an error indication. 2. Otherwise, optarg shall point to the string following the option character in that element of argv, and optind shall be incremented by 1. Thanks, Michael --- a/getopt.3 2012-03-06 11:33:58.252003620 +0200 +++ b/getopt.3 2012-03-06 11:33:36.0 +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 -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662781: getopt.3 has a bad example, as is evident in #655685 report
--- On Tue, 3/6/12, Michael Kerrisk (man-pages) wrote: Hi. Upstream maintainer of man-pages here. I'm not at all sure that the problem in #655685 is because of getopt(). (How did you conclude that it is?) The Debian maintainer think so. Based on what is written at http://bugs.debian.org/655685, I think it is unlikely not to point to getopt. Allowing a space between option character and argument is longstanding UNIX (and Linux behavior), and as far as I can see POSIX is explicit in allowing it I was just trying to make the manual page accurately document the actual behavior of the program. Do you think I should close my report, and file a bug to libc (assuming this is not yet reported)? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662781: getopt.3 has a bad example, as is evident in #655685 report
On Wed, Mar 7, 2012 at 11:21 AM, Regid Ichira regi...@yahoo.com wrote: --- On Tue, 3/6/12, Michael Kerrisk (man-pages) wrote: Hi. Upstream maintainer of man-pages here. I'm not at all sure that the problem in #655685 is because of getopt(). (How did you conclude that it is?) The Debian maintainer think so. Based on what is written at http://bugs.debian.org/655685, I think it is unlikely not to point to getopt. Allowing a space between option character and argument is longstanding UNIX (and Linux behavior), and as far as I can see POSIX is explicit in allowing it I was just trying to make the manual page accurately document the actual behavior of the program. Do you think I should close my report, and file a bug to libc (assuming this is not yet reported)? 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. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of The Linux Programming Interface; http://man7.org/tlpi/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
