Previous

Release v0.5.0 - Basic yet adaptable configuration

Current

Release v0.6.0 - Better argument parsing

Next

Release v0.7.0 - TextBuffer and partial attribute markings

Release v0.6.0 - Better argument parsing

The latest release of JCLI has been released, mostly featuring improvements to argument parsing.

Changes

The following changes were implemented:

  1. Feature - Add text.d and move IHelpContent.lineWrap into it.
  2. Feature - Line wrapping now supports suffixes.
  3. Feature - You can now explictly set the value of a boolean argument, instead of it always being true.
  4. Feature - Add ArgPullParser.unparsedArgs.
  5. Feature - Add ability for commands to store a "raw arg list".
  6. Tweak - Coloured logging defaults to being on.
  7. Tweak - ArgBinder will now selectively show the "This binder is templated..." only if the binder is actually a template in the first place.

Raw Arg Lists

I feel this is easiest explained by an example.

Take dub for example, when using dub run you can specify parameters to pass to your application via the following: dub run -- value1 value2 value3...

I wanted to add support for this in CommandLineInterface, which is pretty easy to use.

On the code side of thing, your command should specify a string[] with @CommandRawArg attached to it:

@Command("example")
struct ExampleCommand
{
    @CommandRawArg
    string[] rawList;

    void onExecute()
    {
        import std.stdio;
        writeln(this.rawList);
    }
}

On the command line side of things, you do exactly the same as you would with dub run, except you use triple dashes instead of double dashes:

> tool.exe example --- value1 value2 value3
["value1", "value2", "value3"]

Explicit bool values

One thing that was bothering me about bool args, was that they are either not defined (on the command line), or defined, yet always true.

This meant that bool args always had to be made Nullable, as that was only the way to make them optional, and therefor the only way to actually let them be false (when not defined).

Now though, the likes of --verbose=false and --verbose=true can work, while still allowing --verbose.

There was also special consideration for things such as tool.exe --verbose arg1 arg2. The issue being, "arg1" preceeds a bool flag ("--verbose") so it would normally be treated as a value, however CommandLineInterface takes special care to only treat a predetermined list of values as a boolean value.

I'd recommend reading the docs for a better idea on what I mean.

I was thinking of allowing things like "--verbose=on/off/yes/no", but then thought that an enum could just be used for that, and it should "just work" due to ArgBinder containing a builtin converter for enums.

Reminder

In the event that there's actually someone else other than me that uses this library, I'd just like to remind you that I'm completely open to suggestions, criticism, PRs, etc.