Does not allow arguments that start with the '@' character

[javierlarota]

static void Main(string param1, string param2)
{
    Console.WriteLine($"Parameters Param1={param1}, Param2={param2}");
}

Fails when invoking the app from command line with a parameter that starts with the "@" character

C:\MyApp.exe --param1 Hello --param2 @World

Response file not found 'World'
Required argument missing for option: --param2

[jonsequitur]

This is intentional. The @ character indicates a response file. https://github.com/dotnet/command-line-api/blob/main/docs/Features-overview.md#response-files

[elgonzo]

To add to @jonsequitur's answer, it is possible to disable response files (and thus treating @World like an ordinary string value) by using CommandLineBuilder. Basically something like this (untested, could contain errors):

using System.CommandLine.Builder;
using System.CommandLine.Parser;


var myRootCmd = ... your normal command(s) setup ...

var parser = new CommandLineBuilder(myRootCmd)
    .ParseResponseFileAs(ResponseFileHandling.Disabled)
    .UseDefaults()
    .Build();

parser.Invoke(args);

[jonsequitur]

There's an interesting question here about how the user rather than the tool developer should specify an argument beginning with "@" when response files are enabled. There should be a way to escape the string but I'm not sure there's one implemented.

[vlada-shubina]

@jonsequitur @elgonzo just fyi, this issue was raised for dotnet/templating in dotnet/templating#4488 as well. In one of the templates, the author uses username option which may start with @. We need to suggest an alternative to escape it.
We don't want to lose response files for dotnet new at this point.

[jonsequitur]

I've been unable to find prior art for escaping a token on the command line that could indicate a response file. Suggestions are welcome. I'll put forward an approach we could take in the absence of a better-established convention.

We looked a bit at escaping using quotes but this tends to get quite confusing when combined with shell escaping requirements, so we discarded it.

My proposal that could be a little easier for users is to prepend an additional @. So in the example where you have a user whose username is @jonsequitur, you could pass this to avoid indicating a response file:

> myapp --username  @@jonsequitur

Of course, communicating the existence of this convention would be a whole other challenge.

Thoughts?

[KalleOlaviNiemitalo]

myapp --username=@text doesn't treat text as the name of a response file. This is a workaround that already works.

I feel even myapp --username @text should not treat text as the name of a response file, if the --username option is known to have arity 1 or greater. But I don't know if someone is relying on the current behavior.

[KalleOlaviNiemitalo]

Possibly a directive could be used… myapp [noresponsefiles] @text

This would be difficult for users to discover, and cumbersome to use interactively. For scripts though, this would be easier than doubling the @ sign, because the script author could just add [noresponsefiles] unconditionally rather than check whether an argument starts with @.

[KalleOlaviNiemitalo]

communicating the existence of this convention would be a whole other challenge.

Could be made part of the error message.

Response file not found 'text'. To specify the argument '@text' without referring to a response file, double the @ sign like this: '@@text'

[jonsequitur]

These are all good suggestions, though I worry that interpreting the @ prefix contextually would be difficult to reason about. Right now we inline the replacement tokens very mechanically, and this happens before parsing begins. It's easy to understand.

A simple escape mechanism and an error message would be pretty simple and effective, I think.