Document or fix -- and @foo broken as parameter argument

[phadej]

With cabal-install-2.4

% cabal v2-build --project-file -- -w ghc-8.4.4  fin
% cabal v2-build --project-file @projectfile -w ghc-8.4.4 fin

works, where -- and @projectfile are actual files on the filesystem.

In current master preprocessing will break this kind of usage.

I'm personally ok with not fixing such corner cases, but they should be documented. I have no idea what are "industry practice" regarding response files, are actual other input files starting with @ simply prohibited?

[phadej]

Thinking more, I think that response files should be handled by argument parser (even as it makes it do IO), not done as preprocessing.

[angerman]

Wouldn’t that eventually lead to a recursive argument parser as you discover more and more arguments as you go?

[23Skidoo]

% cabal v2-build --project-file -- -w ghc-8.4.4 fin

This actually still works with HEAD.

[23Skidoo]

I think that response files should be handled by argument parser (even as it makes it do IO), not done as preprocessing.

gcc does this as a preprocessing step. Also, unlike GHC.ResponseFile, it supports expanding response files recursively, but expands at most 2000 files to prevent infinite recursion.

[23Skidoo]

Another interesting difference is that gcc skips non-existent response files:

$ gcc @.c 
$ ./a.out 
Hiy@!
$ cp response-file .c
$ gcc @.c            
$ ./a.out            
Hiya!

[phadej]

@23Skidoo thanks for the research!

[hvr]

Another interesting difference is that gcc skips non-existent response files

Fwiw, I've noticed that quite some tools do this (e.g. ar, clang, ld, nm)

So it appears to me there's an established convention to only expand response files if they exist, and otherwise pass on the @arg to the CLI parsing unexpanded

and in fact, this is documented in man-pages, e.g. for ar

@file Read command-line options from file. The options read are inserted in place of the original @file option. If file does not exist, or cannot be read, then the option will be treated literally, and not removed.

Options in file are separated by whitespace. A whitespace character may be included in an option by surrounding the entire option in either single or double quotes. Any character (including a backslash) may be included by prefixing the character to be included with a backslash. The file may itself contain additional @file options; any such options will be processed recursively.

[23Skidoo]

ar, ld, nm, and gcc probably all use the same expandargv implementation from libiberty. LLVM has its own response file parser, but they strive to be compatible with gcc.

If we decide that the convention established by gcc should also be followed in Haskell land, I think we should make this change in base first.