Repository navigation
[API Proposal]: Expose API for escaping command-line arguments #119200
Description
Background and motivation
The core logic is in an internal PasteArguments.AppendArgument. But it's not exposed directly for users usage.
While ProcessStartInfo today already supports passing a list of unescaped arguments (ArgumentList property), it cannot be used together with Arguments property.
API Proposal
namespace System.Diagnostics;
public class ProcessStartInfo
{
public static string EscapeArgument(string argument);
}API Usage
// Fancy the value
var info = new ProcessStartInfo()
{
FileName = ...;
}
var builder = new StringBuilder();
builder.Append(myAlreadyEscapedArgumentsComingFromElsewhere);
foreach (var arg in listOfUnescapedArguments)
{
builder.Append(ProcessStartInfo.EscapeArgument(arg));
}
info.Arguments = builder.ToString(); Real-world example is SDK:
There, Module.RunProperties.Arguments is already a single string which can contain multiple arguments like --report-trx --results-directory "Path Containing Spaces" which is already escaped properly.
Then, there are multiple more arguments that need to be constructed and are not escaped.
NOTE: ArgumentEscaper.EscapeSingleArg implementation seems like it's already diverging from the implementation in dotnet/runtime. And somewhere in dotnet/msbuild there is even another implementation somewhere.
Alternative Designs
Allow both ProcessStartInfo.Arguments and ArgumentList to be used together.
Risks
No response
Activity
dotnet-policy-service commentedon Aug 29, 2025
Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.
MihuBot commentedon Aug 29, 2025
I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):
adamsitnik commentedon Aug 29, 2025
ArgumentListpredates me as an owner of System.Diagnostics.Process, but my understanding is that it was designed as the new, recommended way of passing arguments to a new process.Argumentsproperty was not removed for backward compat reasons.So instead of:
The users can forget about escaping and just provide the args:
And in your case you have some pre-concatenated string with some escaped args and you would like to add some more to it?
Youssef1313 commentedon Aug 29, 2025
Yes. In my case I have already a single string that is properly escaped already. So I think an alternative is to provide an API to "unescape" it, then use
ArgumentList?adamsitnik commentedon Aug 29, 2025
System.CommandLine (already used by the SDK) provides an API for that:
https://github.com/dotnet/command-line-api/blob/fab13a397461f4ff16b988ba96cb08891ac75257/src/System.CommandLine/Parsing/CommandLineParser.cs#L40
This test shows how it works: https://github.com/dotnet/command-line-api/blob/fab13a397461f4ff16b988ba96cb08891ac75257/src/System.CommandLine.Tests/SplitCommandLineTests.cs#L36-L41
But back to your original request for now I am hesitant of adding such API. You are the first user asking for it since
ArgumentListwas added in .NET Core 2.1 (8 years ago?) I would prefer to wait and get more up votes/feedback for a whileKalleOlaviNiemitalo commentedon Aug 29, 2025
CommandLineParser.SplitCommandLine(string commandLine) matches neither CommandLineToArgvW nor POSIX
shword splitting.From where do you get the "single string that is properly escaped already": is it built by some API, or read from a file edited by a user?
Youssef1313 commentedon Aug 29, 2025
@KalleOlaviNiemitalo For the case of SDK, that's
RunArgumentsMSBuild property (coming from user)jkotas commentedon Aug 29, 2025
Related: #668