And putting a trailing space also worked around the problem when running that from Perl.

It used to be that Perl's system() on Windows would try running the command you gave directly first and would only resort to wrapping it in qq(cmd /c "...") if that failed. I think that, over the years, enough edge cases showed up that the details of this technique were changed in order to try to get more "expected behavior" in more cases. If you are interested in details, then check out the source code involved, p5git://win32/win32.c..

Interesting point - this indeed explains (and it is also interesting that the quoting problem only shows up when we invoke the background version, but not the "normal" call to system).

It used to be that Perl's system() on Windows would trying running the command you gave directly first and would only resort to wrapping it in qq(cmd /c "...") if that failed. I think that, over the years, enough edge cases showed up that the details of this technique were changed in order to try to get more "expected behavior" in more cases.

Would this mean that in newer versions of Perl, the "foregroun" system() would show the same problem? I thought of using system() instead of system(1,...) and doing an explicit fork and exect, to avoid the quoting bug, but if newer Perl versions will consistently wrap the argument inside an extra invocation of cmd /c, the problem would reappear if I upgrade to a newer Perl :-(

Just for y'all's information, I don't know the answer to that. It would be interesting to look into why only system(1,...) wraps things in cmd /c "..." in a way that triggers this bug. To figure that out, I'd read the code that I linked to above. I did scan some parts of it earlier but not looking for that quirk (I initially missed your point that the "1," was required).

But why not just include a trailing space and then none of that will likely matter? (And include a comment noting that the trailing space is required to work around a bug in: cmd /c "cmd /c ...".)