.NET command line parsing
For a project I’m working on I needed an assembly that would easily parse a command line.
“A command line? What’s that?” you might ask. I understand that most of the programs you run always start up with a GUI that you can then use to set up all your parameters. This is not always the Right Thing to do. A lot of what I program are utility programs that do things to files in a scripted (or batch) mode. GUIs, in this case, just get in the way. Thus the command line - you tell the program what to do when you start it up and it never talks to you again.
For example:
playMP3 --directory /myhome/music --background true
The convention is that a long name option has two preceding - (dash) characters and a short name option (a single character) has a single preceding dash character.
There are certainly a lot of options out there for doing this sort of thing, but I can be sort of an odd person - if I’m using a language, I want to use the language; not write in a language I’m comfortable in and just use the syntax of the new language.
That may be a difficult concept to visualize if you’re not a programmer. Hopefully someone can comment and give an example in the non-programming world, but I can give a programming example. I once worked with a programmer that had done most of his work in COBOL and he was very good at it. Times change, and he needed to be programming in C. C is not like COBOL at all. It is, after all, meant to do different things.This person wrote C programs and they compiled and they worked
However, one look at his source and you could tell that his mind was still writing COBOL. He wasn’t taking advantage of many of the features that C has and the program was structured as if it were in COBOL. He got the job done, but it could have been done better.
So, to get back on track, I was looking for an assembly that could do command line processing that externally looked like all the other command line processing I was familiar with, but internally it was written as a C# program.
I searched Google and found a lot of candidates, but one named Command Line Parser Library seemed to fit the bill very well. I downloaded and compiled it, sorted out the documentation, and started using it.
Well, I’m an iterative developer and as I expanded the utility program I was writing I found that this particular assembly was not capable of doing one thing I needed it to do. No worries, there are a lot of choices out there so I went back to Google and did some more looking. I found that the assembly I was already using really was easy to use and was so close to being what I needed that I contacted the author and talked to him about it.
He asked me to make an entry on the web site and he’d try to sort out how to accomplish what I needed. He already had a similar feature, used for trailing arguments, but I needed to be able to do things just a bit different. If he didn’t have the time and/or inclination to add this feature then I was prepared to delve in to the code to add it myself.
However, just today he released a new version with my feature added. Very cool.
He apologized for it taking so long, but since I knew he was working on it, the time it took hadn’t bothered me. Not having this feature hadn’t been holding me up because I had a lot of other development to work on. Now I can go back and update the code and take advantage of this newly added feature.
Why am I blogging about this? Just because I think it’s important to acknowledge that a substantial amount of good work is going on in the small development shops. If he’s like me (and it sounds like he is) the definition of “development shop” is him sitting in front of his computer in the basement or spare room whenever you have the time to work on writing code for fun. He’s not getting paid for this, he’s scratching an itch and that’s something I can identify with.
Explore posts in the same categories: Coding
