Re: command line parsing

From: Vladimir Prus (yg-boost-users_at_[hidden])
Date: 2003-04-16 03:03:34

cl_corba_at wrote:

>> I guess that's the right job for boost::tokenizer...
> 
> The problem is, that a command line seperator for the tokenizer is not
> provided by boost, so you rely on external code.

I assumed you only have to separate on whitespace, so existing tokenizers
will do.

> If I use the tokenizer, I have to parse the arguments, copy them in a
> vector and then pass it to your module.

Yep, but is this a problem. Something like:

   boost::tokenizer<...> tok(...);
   options_and_arguments oa = 
        parse_command_line(vector<string>(tok.begin(), tok.end()));

(Of course, provided there's something you can put in "...")
 
>> Frankly, I've missed the WinMain case, and not sure what to do.
>> The problem is that single string might erase important
>> information --- what happens if you have command line argument
>> with embedded space.
> 
> Embedded spaces should be placed in quotation marks which should be
> removed by the tokenizer. Arguments could be seperated by one ore more
> space.

Do you mean that if I type

   program "a b c" "C:/Program files"

then the program will receive this string, with quotes there? (The linux
shell will strip quotes completely). If this is so, then it's possibe to
implement. For example, the following program:

   #include<iostream>
   #include<boost/tokenizer.hpp>
   #include<string>

   int main(){
      using namespace std;
      using namespace boost;
      string s = "program \"a b c\" \"C:/Program files\"";
      typedef escaped_list_separator<char> separator;
      typedef tokenizer<separator> tokenizer;
      tokenizer tok(s, separator('\\', ' ', '"'));                                             
      for(tokenizer::iterator beg=tok.begin(); beg!=tok.end();++beg){
          cout << *beg << "\n";
      }
   }

Will output:
    bash-2.05b$ ./a.out
    program
    a b c
    C:/Program files

Is this solution is OK? (The only problem is that adjuacent spaces are
mishandled, but that's fixable).

>> Maybe, using __argv/__argc,
>> as suggested by Nuno Lucas is just better.
> 
> This is what I will use now, but what I don't like on this solution is
> that it is compiler dependand.

I understand your concerns. Is the solution above is sufficient, I can move
it into the library. OTOH, I'd rather not to reimplement all the windowns
shell quoting rules inside program_options (especially and I don't seem to
understand them). 

- Volodya