jpdillingham / Utility.CommandLine.Arguments

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

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fails to read argument strings starting with /

StefanH-AT opened this issue · comments

When reading an argument of which the value starts with /, an empty string is returned. This is critical as I can't take in absolute file paths without this.

If you're passing a value with no key, e.g. app.exe /some/path, the argument will be placed in the Operands list, starting in the second index:

$ dotnet Echo.dll /bar/baz
{
  "ArgumentDictionary": {},
  "ArgumentList": [],
  "CommandLineString": "C:\\Users\\...\\Utility.CommandLine.Arguments\\examples\\Echo\\bin\\Debug\\netcoreapp2.1\\Echo.dll \"C:/Program Files/Git/bar/baz\"",
  "OperandList": [
    "C:\\Users\\...\\Utility.CommandLine.Arguments\\examples\\Echo\\bin\\Debug\\netcoreapp2.1\\Echo.dll",
    "C:/Program Files/Git/bar/baz"
  ],
  "TargetType": null
}

Alternatively, you can supply the value along with a key, e.g. app.ext --some-file /some/path and it will end up in the configured property.

If this doesn't help please follow up with an example of your input string so I can troubleshoot.

I'm using a key. If i put /home/....., I get null, but home/... gets me the correct string
Selection_135

[Argument('c', "config", "Set the config file path. Default: ./config.json")]
private static string ArgConfigPath { get; set; }

All values work fine as long as they don't start with /

I've been able to confirm the bug; it breaks everywhere except in Git Bash/MINGW64 on Windows, which happens to be what I use most of the time. Specifically, any path starting with a forward slash in this scenario is resolved to <git binary location>/input and the resulting path doesn't begin with a forward slash so I never noticed it.

I can't really add a test case for this because it isn't a parsing issue due to my (regrettable, at this point) decision to allow forward slashes as a key delimiter.

I think the the most reasonable thing to do here is to make forward slash support opt-in, which will introduce a breaking change but will enable support for absolute paths on GNU/Linux by default.

I'll start working on this shortly.

Still not fixed? My program kinda relies on this

Thanks for your patience. This is resolved with the 5.0.0 release.