jpdillingham / Utility.CommandLine.Arguments

A C# .NET class library containing tools for parsing the command line arguments of console applications.

Home Page:http://dillingham.ws/tools/CommandLine.Arguments-Simple-Parsing-of-Command-Line-Arguments/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Arguments starting with non-Alpha characters followed by Forward slashes are dropped completely

Barryrowe opened this issue · comments

I believe #55 introduced an additional bug where arguments that begin with a non-alpha character .~ followed by a forward slash / are not captured and are parsed as empty strings.

This does not change whether quoted or not.

Given an Argument like:

[Argument('f', "folder", "The folder location for some thing.")]
private static string FolderPath { get; set; }

These will fail to populate the FolderPath property:
dotnet someapp.dll -f "../../path/in/parent"
dotnet someapp.dll -f ../../path/in/parent
dotnet someapp.dll -f "~/path/from/root"
dotnet someapp.dll -f ~/path/from/root

Environment Details:
.NET version: dotnet core 2.2.207
Repro OS: macOS 10.14.6
PackageVersion: 3.0.1

This may be OS specific; I tested it on Windows and Linux and it works as expected:

dotnet Echo.dll -f "../foo"

{
  "ArgumentDictionary": {
    "f": "../foo",
    "home/jp/source/repos/Utility.CommandLine.Arguments/examples/Echo/bin/Debug/netcoreapp2.1/Echo.dll": ""
  },
  "ArgumentList": [
    {
      "Key": "home/jp/source/repos/Utility.CommandLine.Arguments/examples/Echo/bin/Debug/netcoreapp2.1/Echo.dll",
      "Value": ""
    },
    {
      "Key": "f",
      "Value": "../foo"
    }
  ],
  "CommandLineString": "/home/jp/source/repos/Utility.CommandLine.Arguments/examples/Echo/bin/Debug/netcoreapp2.1/Echo.dll -f ../foo",
  "OperandList": [],
  "TargetType": null
}

Would you mind running the Echo example with your input and sharing the output?

Okay, so that seems to work as expected. I tried updating to target dotnet 2.2 to see if there was some dotnet regression but that works as well. Then it dawned on me "duh, this is master"

I checked out the 3.0.1 tag to try and verify but that works as well. I can consistently get it to fail in our project pulling in the 3.0.1 nuget package. Upgrading to 4.0.0 resolves it, so sorry for the confusion. Now I'm just curious why the 3.0.1 tag doesn't reproduce the problem, but it exists in the released binary.

Anyway, latest release resolves it, so closing.