When executing CDK apps, users specify the command as a string. The only feasible interpretation of that is by executing the command line through a shell, either bash or cmd.exe.

We are using shell execution on purpose:

• It's used for tests
• It's necessary on Windows to properly execute .bat and .cmd files
• Since we have historically offered it you can bet dollars to doughnuts that customers have built workflows depending on that.

This is all a preface to explain why we don't have an argv array. Automated code scanning tools will probably complain, but we can't change any of this. And since the source of the string and the machine it's executing on are part of the same security domain (it's all "the customer": the customer writes the command string, then executes it on their own machine), that is fine.

On that string the user gave us, historically we did do a bit of trivial parsing and preprocessing of that string in order to help the user achieve success. Specifically: if the string pointed to a .js file we would run that .js file through a Node interpreter, even if there would be potential misconfiguration obstacles in the way:

• We're on POSIX and the file was not marked as executable (can happen if the file is freshly produced by a tsc invocation); or
• We're on Windows and there is no shell association set up for .js files on Windows.

In both cases we would prepend our own Node executable's path to the command line in order to successfully run the "naked" .js file.

That behavior used to fail in the following cases:

• If the pointed-to file had spaces in its path.
• If Node was installed in a location that had spaces in its path.

In this PR we document the choice of command line string a bit better, and handle the cases where the file or interpreter paths can have spaces in them.

We still don't do fully generic command line parsing, because it's extremely complex on Windows and we can probably not do it correctly; we're just concerned with quoting the target and interpreter.

Historically it has been possible (though not widely documented) for the { "app" } entry to contain a string[] (argv array). We traditionally used to join this back to a single space-separated string, even without applying quotes, so you wouldn't really benefit from that. Nevertheless, this PR retains that behavior.

Closes #636

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license