Making Command Line Arguments Easier [Matt Ellis]

BCL Team Blog Making Command Line Arguments Easier Matt Ellis | Quick Diets

BCL Team Blog Making Command Line Arguments Easier Matt Ellis | Quick Diets — Tue, 09 Jun 2009 14:22:17 GMT

PingBack from http://quickdietsite.info/story.php?id=12129

BCL Team Blog Making Command Line Arguments Easier Matt Ellis | Cast Iron Cookware

Wed, 03 Jun 2009 22:42:20 GMT

PingBack from http://castironbakeware.info/story.php?title=bcl-team-blog-making-command-line-arguments-easier-matt-ellis

Hi from the New Guy [Matt Ellis]

BCLTeam's WebLog — Tue, 31 Oct 2006 22:10:59 GMT

As one of the newest members of the BCL team, I wanted to take some time to introduce myself. I’m Matt

re: Making Command Line Arguments Easier [Matt Ellis]

giovanni.costagliola — Tue, 27 Jun 2006 11:32:37 GMT

Take a tour of getopt GNU library.

Btw, it would be nice to have a short and long form for a swith.
e.g.: -f <==> --file
the possibility to imply a default set of values if a flag is used
e.g. -x ==> -A -B
the possibility to definy a "mandatory-set" of flags
e.g. {-a, -b, -c}, I mean, if U use one of them you must use all the others

and obviously a re or better a domain constraint on the possibile values

re: Making Command Line Arguments Easier [Matt Ellis]

giovanni.costagliola — Tue, 27 Jun 2006 11:32:29 GMT

re: Making Command Line Arguments Easier [Matt Ellis]

Jeremy Wiebe — Tue, 20 Jun 2006 16:49:51 GMT

Just a few random comments:

1. Re: David Levine's comment #8. I believe the Windows command prompt will properly handle paths with spaces, etc in them. (Although the parser would have no way of telling what to do with this, for example:

myapp.exe -f C:\Document and Settings\myuser\file.txt

There's probably some hueristics to "guess" where file.txt resides, but probably not 100% correct all the time.

2. Having the ability to specify either long and/or short parameter variants would be nice.

For example:

myapp.exe -f=test.txt

... should be the same as...

myapp.exe -file=test.txt

Specifying both long and short parameter names should be optional (so that some parameters may only have a "short" variant and some only a "long" variant.)

3. Case sensivity of parameter names should be supported (but optional).

re: Making Command Line Arguments Easier [Matt Ellis]

Christoph Richter — Tue, 20 Jun 2006 12:07:43 GMT

hmm... what i miss most? that there is no standard for getting the help about an commandline (/? /h /help -?,....). have no real problem about how i have to give it in, if i can read it somewhere. so really make an default implementation for an commandline tool, where you write your help text. e.g. with an dictionary where you add the param pattern and the explanation for that pattern and .net writes out the help on /? or whatever

re: Making Command Line Arguments Easier [Matt Ellis]

David Levine — Mon, 19 Jun 2006 15:50:32 GMT

Some thoughts n addition to the above...

1. Should be able to specify a response file that contains some or all the command line arguments; the parser should not care where the argument came from. This will make it much easier to have tools automatically generate the argument list. For example... @list=<fileName>

2. Default ordering should be order-independent. I can't think of any use cases where I want the arguments to be order dependent, but if so, then it should be an option that must be explicitly enabled.

3. Should be able to handle a number of different methods of specifying arugment data, such as /a=SomeValue or -a:aValue, or any number of other combinations.

4. Getting the parser to handle quotes and embedded quotes is important.

5. I prefer that the ability to specify argument dependencies and other validation be handled by the application after parsing is complete. If you want to build it in then I prefer that it use an extensible mechanism defined by the parser and implemented by the application. There are so many variables that it should be left to up to the application to determine whether or not the arguments are valid. A simple heuristic of "arg B can exist only if arg A exists" is unlikely to be of much value and is not very flexible.

6. The parser should be able to generate the command line from input arguments; i.e. an Unparse method. This is useful for tools/batch files that invoke other tools.

7. The generated command line must be capable of correctly round-tripping through the parser.

8. Paths and embedded quotes must be handled correctly. e.g. if a string contains an embedded space then it should be surrounded by quote marks unless it already is surrounded by quotes.

9. Should handle environment variables.

Hope you enjoy your stay at MSFT.

re: Making Command Line Arguments Easier [Matt Ellis]

David Banister — Sat, 17 Jun 2006 22:42:53 GMT

What I think is most important is usability. In my opinion any logical way of specifying options should be acceptable. All of the following should do the same thing, but I that I lot of people would disagree with the last couple:

thingy a b c
thingy -a -b -c
thingy /a /b /c
thingy abc
thingy a /b -c
thingy /ab-c

re: Making Command Line Arguments Easier [Matt Ellis]

Tomer Gabel — Sat, 17 Jun 2006 10:26:56 GMT

One feature that is often neglected in command line parsers is the ability to specify "debug-level" flags. Parameters that are flagged as debug-level should work exactly the same as other parameters, only they mustn't show in the automatically-generated "Usage:" printout.