[Mono-list] Command Line Options on Windows and Linux

[Jonathan Pryor]

On Mon, 2010-10-04 at 19:47 -0700, Charlie Poole wrote:
> I'm using Mono.Options for nunit-console 3.0 and I'm running into
> a bit of a conflict of philosophy about chars that start options.
> 
> NUnit has historically NOT recognized args starting with '/' as
> options on Linux, although it does allow them on Windows.
> 
> Mono.Options recognizes '/' as starting an option in all environments.
> 
> Each approach causes different problems. The Mono.Options
> approach seems to make it impossible to use any path that starts
> /xxxx, where xxxx is the name of a program option.

My apologies that this will sound glib, because...well, it'll sound
glib.  Again, I'm sorry.

 1. I seriously doubt that there will be that many conflicts between 
    program option names and Unix paths.  Do you really intend on having
    /bin, /etc, or /tmp options?  No existing options in nunit-console
    have conflicts with Unix filesystem paths.

 2. It's trivial to avoid/bypass the Mono.Options logic.  Gonzalo 
    mentioned using '--', which is one approach.  Another is to
    "double" the slash -- "//tmp" CANNOT match a "/tmp" option.

One final note is that Mono.Options uses a single-pass parsing algorithm
and is NOT recursive.  This means that if you have an option which
requires a value, the value can match the name of an option but won't be
interpreted as an option.  Consider:

        var tmpdir = null;
        var o = new OptionSet {
                { "tmp=", v => tmpdir = v },
        };
        o.Parse (new[]{"/tmp", "/tmp"});  // i.e. "myapp /tmp /tmp"

After the above executes, the 'tmpdir' variable will have the value
"/tmp", because once "inside" an option all remaining options will be
"eaten" until the option has all the values it requires.  (Most options
that requires values only require one value, but this can come in
handy/add confusion if an option requires e.g. 2 values...)

If there's a crucial need to more strictly control the character used to
introduce options I will consider adding that functionality, but (at
least on Unix) it won't actually change anything.  Nothing on Unix
prevents you from creating a file named "-Rf", and `rm -Rf` won't remove
the file named "-Rf" -- you'd need to do `rm ./-Rf` -- so requiring that
'-' be used to introduce options on Unix doesn't avoid this problem, it
merely moves it slightly.

 - Jon