Making Command Line Arguments Easier [Matt Ellis]

Before we get to the meat of this blog post, I want to take a moment to introduce myself. My name is Matt Ellis and I’m working this summer as an intern on the Base Class Libraries team. I’m really enjoying my time here, and it’s pretty amazing to be working on a team whose work affects so many developers around the world!

 

One feature we are considering adding to a future release on the .NET Framework is a library to help developers writing applications that use command line arguments. We’d like to be able to provide a simple framework for parsing these arguments so our users don’t have to waste time writing boilerplate code that extracts and validates arguments from the string array passed into the main method, and can instead focus on solving the problem at hand.

 

            The Windows PowerShell team has developed some framework to solve this problem in their space. One of the key concepts in PowerShell is the Cmdlet, which is a small .NET class run within PowerShell to perform a specific task. Authors of Cmdlets simply declare, via attributes within their code, properties and fields that should be used as command line arguments. PowerShell takes care of filling in these fields and properties based on arguments that come in from the command line. PowerShell makes sure the types of incoming arguments are valid, that all mandatory arguments are given values and can even print usage information for an application. You can read more about PowerShell by downloading the Microsoft Windows SDK for Beta 2. This is all really cool technology, but it requires PowerShell. We’d like to be able to deliver a solution that would only require the .NET Framework.

 

            So we want to ask you, our customers, what features you’d like to see in a command line argument parser. For example, is the ability to have order dependent parameters important, or should copy -A -V source.txt dest.txt work the same as copy -V -A source.txt dest.txt or copy source.txt dest.txt -A –V? What about the ability to specify dependencies between arguments, such as –A can only appear if –B is also somewhere on the command line? What features are most important to you when it comes to writing programs that take command line arguments?

Comments

• Anonymous
  June 16, 2006
  The comment has been removed

• Anonymous
  June 16, 2006
  The comment has been removed

• Anonymous
  June 16, 2006
  The comment has been removed

• Anonymous
  June 17, 2006
  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
  

• Anonymous
  June 19, 2006
  The comment has been removed

• Anonymous
  June 19, 2006
  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

• Anonymous
  June 20, 2006
  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 Settingsmyuserfile.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).

• Anonymous
  June 26, 2006
  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
  

• Anonymous
  June 26, 2006
  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
  

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

• Anonymous
  June 03, 2009
  The comment has been removed

• Anonymous
  June 08, 2009
  PingBack from http://quickdietsite.info/story.php?id=12129