CliParser seemingly intentionally violates standard CommandLineToArgvW behaviour in https://github.com/dotmake-build/command-line/blob/ed8670b6ec273c61d45306496a711e4e4eeb5173/src/DotMake.CommandLine/CliParser.cs#L247
This results in there being no way to supply an argument ending with one or more quotes. For a very concrete example, we have a
tool that can query some large json files using a Dynamic LINQ expression. The following PowerShell command:
searchtool file.json -e 'CompanyRegistrationNumber == "24256790"'
is turned into the command line:
searchtool file.json -e "CompanyRegistrationNumber == \"24256790\""
.net parses the argument tail correctly into the args array ["file.json", "-e", "CompanyRegistrationNumber == \"24256790\""]
But the Expression property on the command, declared as
[CliOption(Aliases = ["-e", "--expr"], Description = "Dynamic Linq expression to use as search predicate.", Required = false)]
public string? Expression { get; set; }
, receives "CompanyRegistrationNumber == \"24256790" instead, causing DynamicExpressionParser.ParseLambda to throw an Unterminated string literal exception.
Changing the default behaviour now would be a breaking change, but I think there should at least be a way to opt out of this non-standard behaviour with a CliSettings property.
CliParserseemingly intentionally violates standardCommandLineToArgvWbehaviour in https://github.com/dotmake-build/command-line/blob/ed8670b6ec273c61d45306496a711e4e4eeb5173/src/DotMake.CommandLine/CliParser.cs#L247This results in there being no way to supply an argument ending with one or more quotes. For a very concrete example, we have a
tool that can query some large json files using a Dynamic LINQ expression. The following PowerShell command:
is turned into the command line:
.net parses the argument tail correctly into the args array
["file.json", "-e", "CompanyRegistrationNumber == \"24256790\""]But the Expression property on the command, declared as
, receives
"CompanyRegistrationNumber == \"24256790"instead, causingDynamicExpressionParser.ParseLambdato throw an Unterminated string literal exception.Changing the default behaviour now would be a breaking change, but I think there should at least be a way to opt out of this non-standard behaviour with a
CliSettingsproperty.