[ OtherBill forgot to copy the list; I'm including it here without cutting ]
On Sat, Nov 25, 2000 at 04:50:19PM -0600, William A. Rowe, Jr. wrote: > > From: Greg Stein [mailto:[EMAIL PROTECTED] > > Sent: Saturday, November 25, 2000 4:40 PM > > > > Speaking of testargs.c ... the "d::" part means that the argument for -d is > > *optional*. Currently, getopt() requires an argument (read: it doesn't > > understand double-colons). > > > > Q: should it understand a double-colon? > > > > [ the man page for getopt() describes the double-colon ] > > Without reading it (just yet)... > > I'd agree that getopt() could understand the required-optional-invalid cases, > and that would be potentially quite useful. The downside to ever using the > d:: syntax is that the parser is easily confused between the -f opt arg > case and the -f arg case (which could be -f opt). Yes, this could be confusing, but "it isn't our problem". The regular getopt() allows this behavior, so it is really a question of whether we want APR's getopt to follow it, too. I'm also fine with saying "sorry, we don't do that because it makes for a confusing cmdline interface." > I'm reminded that apr needs to address the fact that 1. filenames contain > spaces (on some platforms >;-) and 2. that x:bleh is a legit filespec. 1. APR doesn't have any problem with spaces. argv[n] can easily be a filename with a space. The getopt() function does look inside the "argument" strings. $ program "file with a space" The quote handling is done by the shell on most Unixen. If Windows doesn't handle the quotes automagically, then you're going to need to come up with a patch :-) 2. Since we don't parse out arguments, we'll never see the ":". > I mention these only to be sure, as we do 'more and more' getopt work, that > we shouldn't break anything :-) > > Bill Sure :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
