Subject: using getopt_long with optional arguments
To: None <netbsd-help@netbsd.org>
From: Jeremy C. Reed <reed@reedmedia.net>
List: netbsd-help
Date: 11/29/2001 12:56:19
I have an switch that can have an optional argument.
static struct option long_options[] =
{
{"daemon", 2, 0, 'd'},
{"port", 1, 0, 'p'},
...
getopt_long(argc, argv, "d::p:",
long_options, &option_index)
If I do "-d 2" it doesn't see the "2". If I do a "-p 1100" it does see the
"1100".
If I do a "--daemon 3" it doesn't see the "3". ("--daemon=3" works.)
And if I do a "--port 1100", it does see a "1100".
I have tried it under the GNU getopt_long and the NetBSD getopt_long. They
both behave this way.
I want to know if that strange behaviour is okay?
Why does required_argument behave differentlty than optional_argument?
Shouldn't the usage be the same?
getopt(3) says: "It does not matter to getopt() if a following argument
has leading white space."
getopt_long(3) says "... the long option's argument may be specified as a
single argument with an equal sign ..." This implies that a space can be
used.
The Single UNIX Specification (2) indicates that "-o arg", "-oarg", and
"-aoarg" should all work.
So I believe that "-D9" and "-D 9" and "--daemon 9" and "--daemon=9"
should work the same.
Jeremy C. Reed
http://www.reedmedia.net/