Closed oold closed 10 months ago
CliWrap already automatically escapes arguments in several overloads. What API are you missing?
While there is an overload that specifies whether the added arguments should be escaped, I need one that forces the escape. The ArgumentsBuilder
checks whether it can short-circuit when attempting to escape an argument. That check is insufficient for programs with custom command line handling, like cmd
.
Example:
I want to call a script, example.bat
, with the argument --some-long-option=abc
. Currently, CliWrap will not escape that argument, no matter what. The script then receives not one, but two arguments: --some-long-option
as %1
and abc
as %2
. cmd
splits at the =
unless the entire argument is quoted.
Hmm, I see. The escaping uses the general command-line rules, not specific to any one shell. It's possible that cmd
is more picky about what special characters need to be escaped. CliWrap uses the same escaping rules as .NET does in Process
: https://github.com/dotnet/runtime/blob/c0c7d3ea4ab741474d598ee56bcd08ecfb38215c/src/libraries/System.Private.CoreLib/src/System/PasteArguments.cs#L10-L79
cmd
is very specific about the format of arguments provided to it. For now, I've copied the Escape()
function and modified it to escape and quote all of my arguments, but it would be handy to have that as a built-in option.
While I understand the use-case, I'm not sure if I want to add shell-specific escaping support, at least yet. I might revisit this in the future, but for now I'd mark it out of scope.
Details
CliWrap can currently cause issues with specific parameters when calling
cmd.exe
. The command line has its own argument splitting logic, as some other programs on Windows also do. Specifically,cmd
splits arguments at commas, semicolons, and equals signs unless the arguments are quoted. Adding support for forced argument escaping would allow users to easily circumvent those issues instead of having to rely on their own argument escaping logic.Checklist