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'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.