Re: [Mono-dev] Lazy man´s Command Line Parser - Revisited

Rafael Teixeira monoman at
Thu Jan 12 09:37:14 EST 2006

Just a thing I have the impression you didn't understand about
Mono.GetOptions, everything is driven by Attributes, you only have to
inherit from the base class for some convenience things like the
automatic --help page. So in that regard your solution is nearly the
same thing.

Just and example:

public class CatLikeOptions : Options
        [Option("display TAB characters as ^I", 'T', "show-tabs")]
        public bool ShowTabs;

        [Option("display $ at end of each line", 'E', "show-ends")]
        public bool ShowLineEnds;

        [Option("use ^ and M- notation, except for LFD and TAB", 'v',
"show-nonp rinting")]
        public bool ShowNonPrinting;

        [Option("equivalent to -vE", 'e', null)]
        public bool ShowLineEndsAndNonPrinting { set { ShowLineEnds =
ShowNonPri nting = value; } }

        [Option("equivalent to -vT", 't', null)]
        public bool ShowLineEndsAndTabs { set { ShowTabs =
ShowNonPrinting = val ue; } }

        [Option("equivalent to -vET", 'A', "show-all")]
        public bool showAll { set { ShowTabs = ShowLineEnds =
ShowNonPrinting = value; } }

        [Option("number nonblank output lines", 'b', "number-nonblank")]
        public bool NumberNonBlank;

        [Option("number all output lines", 'n', "number")]
        public bool NumberAllLines;

        [Option("never more than one single blank line", 's', "squeeze-blank")]
        public bool SqueezeBlankLines;

        [Option("(ignored)", 'u', null)]
        public bool Ignored;

        [Option("output version information and exit", "version")]
        public override WhatToDoNext DoAbout()
                return base.DoAbout();

        [Option("display this help and exit", "help")]
        public override WhatToDoNext DoHelp()
                return base.DoHelp();

        public override WhatToDoNext DoHelp2() { return WhatToDoNext.GoAhead; }

        public override WhatToDoNext DoUsage() { return WhatToDoNext.GoAhead; }

        public CatLikeOptions(string[] args) : base(args) {}

        protected override void InitializeOtherDefaults()
                ParsingMode = OptionsParsingMode.Both |
OptionsParsingMode.GNU_D oubleDash;
                BreakSingleDashManyLettersIntoManyOptions = true;


public class Driver {

        public static int Main (string[] args)
                CatLikeOptions options = new CatLikeOptions(args);

If you run this program this way, you'll get:

: mono mcat.exe --help
mcat - (c)2005 Rafael Teixeira
Simulated cat-like program

Usage: mcat [options] [FILE]...
Concatenate FILE(s), or standard input, to standard output.
  -A --show-all          equivalent to -vET
  -b --number-nonblank   number nonblank output lines
  -e                     equivalent to -vE
  -E --show-ends         display $ at end of each line
  -n --number            number all output lines
  -s --squeeze-blank     never more than one single blank line
  -t                     equivalent to -vT
  -T --show-tabs         display TAB characters as ^I
  -u                     (ignored)
  -v --show-nonprinting  use ^ and M- notation, except for LFD and TAB
     --help              display this help and exit
     --version           output version information and exit

With no FILE, or when FILE is -, read standard input.

Please report bugs to <rafaelteixeirabr at>


So one have to really write less  than 10 lines of 'imperative' code
to accomplish all that.

Nayway, thanks for your efforts and code, I think many programmers
will find it useful.


On 1/12/06, Oscar Forero <oforero at> wrote:
> Hello,
> I discussed on IRC some points over my parser in the mono channel; more or less seems that the people do not want to
> know anything about it; and that many are happy with Mono.GetOptions.
> I still think mine is a superior solution, simple because it does a lot more that Mono.GetOptions; some of the negative
> comments and my answers to them:
> 1. Is not intuitive: Well following a naming convention and/or using Attributes is pretty easy, and should be at least
> as easy as extending a class.
> 2. It takes a lot of reading to know which parameters are supported: Well not really, if you want to know how to use a
> program, let it run with out command line and the help will tell you how it work, if you want to know which parameters
> are supported by a given operation go to the method. It is that easy, now i agree you can have a quicker overview over
> all the parameters in the application with Mono.GetOptions, but if you need to know which parameters are use in a given
> operation you have to read yourself through a lot of If s see what method is being call, go there and read some more.
> 3. It is not maintainable, if you need to add a parameter (the same) to many operations you need to go to every method
> and add it by hand: Well that is actually a problem, but i already have a solution for that, and is call
> ExpandableParameters, you can use any class with public fields an default public constructor as a method parameter, if
> you mark the method parameter as [Expandable] it will use that class to add more parameters to the operation, and you
> will get an instance of the object with the fields properly filled. Now i know that public fields are not really the
> best way to do it, but it was the fastest way to probe the concept. I will like to know if there is any interest in
> having support for properties instead of fields.
> I think this last addition solved the biggest name problem with it, in that way you can have a centralized object where
> the parameters are, with the advantage that you can have different classes grouping parameters, not only one. And is
> still possible to get the command dispatching saving you having to write all that if chains, and using control
> booleans.
> Take a look on the OnExample method of the example code.
> regards,
> Oscar.
> PS: Next add is support for serialized objects as parameters.
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at

Rafael "Monoman" Teixeira
As I'm currently working a lot with Java and even fixing Java VMs
(JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the
title (Javaman) from my friend Bruno Souza and become the
MonoNJavaMan. Yeah, I may currently be crazier than usual...

More information about the Mono-devel-list mailing list