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/