Allow file references anywhere in the command line.

[oznetmaster]

Currently, the --testlist option allows a file containing a list of tests to be specified in the command line.

It may make sense to provide a more general mechanism for allowing files of arbitrary text to be specified on the command line.

This would replace the --testlist option.

One possibility would be to allow something like [<filepath>] to be used anywhere on the command line, and would result in the entire contents of the file being inserted in the command line at that point. All newlines in the file would be converted to spaces.

In fact, the only thing on the command line could be a file reference, and the entire command line would then be retrieved from the file.

As an extension, it might be useful to allow an extension to this syntax [<filepath>,<delimiter>], where <delimiter> would specify the string that newlines would be replaced with in the file (for instance a comma).

File references should be nestable up to some limit (three, perhaps).

The processing of the file references would occur at the top level, before any actual parsing of the command line occurred.

[CharliePoole]

I like the idea of allowing options - and possibly even the names of assemblies - to be placed in some sort of response file. I don't want to over-engineer it however, especially since we would be originating this feature ourselves, rather than in response to user request.

Some thoughts...

What about the use of @filename, which is used by some other programs? The contents of filename would simply be inserted in the command-line, just as you are suggesting.

We may not want to completely replace --testlist, since it is used for simple lists of tests, one per line, usually generated by external programs. Although... it would only require such programs to put --test at the start of each line.

Nesting seems unnecessary as does the specification of delimiters.

[CharliePoole]

We will, of course, have to decide what command-line we are talking about: console, nunitlite or both.

[oznetmaster]

Well, I am a user, and I need it badly, since CF has such a short command line limit.

Almost all my tests already use the --testlist option if there are more then two or three tests in the list (using full names), and that has hit the command line limit on a couple of occasions.

[oznetmaster]

@filename is fine for me, as long as it will not be confused with any other commandline object element.

Reason for the delimiter is that it allows things like --testlist to be emulated, where the tests can be listed one per line, and they are processed correctly. Without it, the tests listed in the file would have to all have commas after them, except for the last one.

[oznetmaster]

Nesting is required if we allow entire command lines in the file. The command line may well need to reference a list of test generated elsewhere, for instance.

[oznetmaster]

I would think we would want to be consistent across both console and nunitlite?

[CharliePoole]

Most likely, we would in this case. I don't think it's so obvious that we
should make it an assumption, that's all.

We can deal with the details when we work this issue for 3.2.

On Tue, Oct 13, 2015 at 9:41 AM, Neil Colvin notifications@github.com
wrote:

I would think we would want to be consistent across both console and
nunitlite?

—
Reply to this email directly or view it on GitHub
#890 (comment).

[oznetmaster]

With the addition of the --p option, this has become more of an issue. On CF, command lines are overflowing even faster.

We obviously did not get to this for 3.2, but it is a real necessity.