https://sourceware.org/bugzilla/show_bug.cgi?id=27594
--- Comment #9 from Martin Storsjö <martin at martin dot st> --- (In reply to Eli Zaretskii from comment #8) > Quoting with backslashes also doesn't work in cmd.exe. The suggestion to > pre-quote the preprocessor is also unreliable, because when `windres` is run > from cmd.exe or from the native MinGW Make, the program's startup code > unquotes the argument, so the result will depend on how many "unquoting" > levels the command line is subject to. I would beg to differ here; when any shell, be it either bash or cmd.exe, interprets a command line, it does split and unescape the command line depending on that shell's rules. It's true that the actual splitting and unescaping happens at different levels (in the caller, in the case of unix shells, and in the callee in the case of a win32 executable), but the basic principle is still the same; if I want to call a tool and have it receive a specific argument, I have to quote that argument according to the current shell's rules (and those rules differ with respect to certain details). So if I want to call windres so that it receives the argument "path to/gcc.exe" -E -DRC_INVOKED, I can call windres with "\"path to/gcc.exe\" -E -DRC_INVOKED" in cmd.exe and in bash - that particular quoting happens to work in both. In bash I could also call it with single quotes and not needing to escape the double quotes, as '"path to/gcc.exe" -E -DRC_INVOKED'. Thomas - the patch that was applied today, in https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=749c700282097cf679ff019a9674d7c762f48619, doesn't that adjust an entirely different thing? The quot() function isn't called for --preprocessor arguments, it's only called for --preprocessor-arg and -D and similar. It still just wraps the whole --preprocessor argument in double quotes, here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/windres.c;h=2b626a29fb68ada1cc012a267a60d72c1335bea9;hb=23182ac0d832477d316547ec2a758d22b43d0837#l889 I'm not arguing that what we have right now is pretty - it's not. But the core issue - that the --preprocessor argument used to accept multiple arguments (and where spaces would have to be pre-quoted) - do you want to willingly break that, which multiple existing projects rely on? I agree that the new interpretation of the option would be more straightforward to deal with - but it is a breaking change that affects multiple projects. I'd rather try to more clearly document the existing original behaviour and how to deal with it. Eli - separately, the new quoting behaviour (that was reverted now, needlessly?) is, in principle a good thing, but it's still missing to quote a few tricky cases - namely backslashes and double quotes. And fixing that would be breaking roughly a similar number of projects. If I want to preprocess with the option e.g. -DSTRING="quotedstring", I want windres to call popen with -DSTRING=\"quotedstring\", so I need to call windres with -DSTRING=\\\"quotedstring\\\". So it would in theory be great if quot() would handle proper escaping of backslashes and double quotes, but if we'd do that change, we'd be breaking those existing users that have codified that case of double escaping for such strings. -- You are receiving this mail because: You are on the CC list for the bug.
