Summary
Malformed quoting inside response files is silently accepted. An unterminated quoted token is dropped, TryReadResponseFile still returns success, and the caller receives a partially parsed or empty argument list instead of a response-file error.
Evidence
src/Platform/Microsoft.Testing.Platform/CommandLine/ResponseFileHelper.cs:13-17
newArguments = [.. ExpandResponseFile(rspFilePath)];
return true;
src/Platform/Microsoft.Testing.Platform/CommandLine/ResponseFileHelper.cs:141-156
if (IsAtEndOfInput())
{
switch (seeking)
{
case Boundary.TokenStart:
break;
default:
yield return CurrentToken();
break;
}
}
string CurrentToken() => commandLine.Substring(startTokenIndex, IndexOfEndOfToken()).Replace("\"", string.Empty);test/UnitTests/Microsoft.Testing.Platform.UnitTests/CommandLine/ResponseFileHelperTests.cs:297-301
string[] result = [.. ResponseFileHelper.SplitCommandLine("\"hello world")];
Assert.IsEmpty(result);
Why this is a real issue
Today an unterminated quote is not treated as an invalid response file. The tokenizer simply returns no token for that input, and TryReadResponseFile reports success because no exception was thrown.
That creates very confusing behavior for users. A typo such as --filter "FullyQualifiedName~MyNamespace.MyClass in an .rsp file does not produce a response-file syntax error; it just drops the quoted argument and lets parsing continue with a different command line than the user wrote. Depending on the surrounding tokens, that can become a misleading arity error or silently change execution behavior.
Suggested resolution
Detect unbalanced quotes while tokenizing response-file lines and fail TryReadResponseFile with an explicit parse error that includes the file path (and ideally the line number). Add coverage for malformed quoted input so the helper no longer reports success on invalid response-file syntax.
Related issues
Summary
Malformed quoting inside response files is silently accepted. An unterminated quoted token is dropped,
TryReadResponseFilestill returns success, and the caller receives a partially parsed or empty argument list instead of a response-file error.Evidence
src/Platform/Microsoft.Testing.Platform/CommandLine/ResponseFileHelper.cs:13-17src/Platform/Microsoft.Testing.Platform/CommandLine/ResponseFileHelper.cs:141-156test/UnitTests/Microsoft.Testing.Platform.UnitTests/CommandLine/ResponseFileHelperTests.cs:297-301Why this is a real issue
Today an unterminated quote is not treated as an invalid response file. The tokenizer simply returns no token for that input, and
TryReadResponseFilereports success because no exception was thrown.That creates very confusing behavior for users. A typo such as
--filter "FullyQualifiedName~MyNamespace.MyClassin an.rspfile does not produce a response-file syntax error; it just drops the quoted argument and lets parsing continue with a different command line than the user wrote. Depending on the surrounding tokens, that can become a misleading arity error or silently change execution behavior.Suggested resolution
Detect unbalanced quotes while tokenizing response-file lines and fail
TryReadResponseFilewith an explicit parse error that includes the file path (and ideally the line number). Add coverage for malformed quoted input so the helper no longer reports success on invalid response-file syntax.Related issues