> feature even on Unix systems. But on Unix systems I think we need to
> at least consider the possibility of real source file names starting
> with '@'. The patch as it stands will have a rather perplexing effect
> if such a file is compiled. Maybe that's OK.
What DJGPP and Cygwin do is thusly: If "@string" is seen, but "string"
does not represent an existing file, the string "@string" is passed to
the program as-is. This allows for arguments (not always file names!)
that start with @, and in most cases where you intend to specify a
file but spell it wrong, the application will usually give a
meaningful error about the odd parameter you've just given it.
This is different from Mark's patch in that Mark's patch will cause
the application to exit when some @string doesn't reflect a response
file.
DJGPP at least also supports simple quoting and recursion in response
files. It also checks for NUL-delimited arguments, from "find
-print0", as an alternative to whitespace-delimited arguments.
Borland C had a similar function for expanding wildcards, which the
user could add to their applications, something like this:
main(int argc, char **argv)
{
expand_wildcards(&argc, *argv);
..
Note that in no case do these expansion functions trigger a fatal
error; they just revert to the original command line arguments if they
can't expand them.
