Newlines in arguments passed to `node -e ...`

[julienp]

We ran into an issue when calling node -e ... with a script that contains new lines. https://github.com/pulumi/pulumi/pull/16649

Repro:

main.go:

package main

import (
	"fmt"
	"os/exec"
)

func main() {
	argWithNewLines := `if (true) {
		console.log("it's true!");
	}`
	cmd := exec.Command("node", "-e", argWithNewLines)
	out, err := cmd.Output()
	if err != nil {
		fmt.Printf("Error: %s", err)
	}
	fmt.Println(string(out))
}

Run with:

go run main.go

When I have the Volta shim node.exe in the path, I get an error:

PS C:\Users\pulumiadmin> go run main.go
Error: exit status 1

With the actual node.exe on path, it works:

PS C:\Users\pulumiadmin> go run main.go
it's true!

[chriskrycho]

Ah, thanks for the report! That is indeed quirky, and we should make sure we pass that through cleanly!

[karthest]

That's weired , it's totally OK on wsl2 ubuntu with volta v1.1.1 and node v20.12.2. Maybe the issue is related to a specific environment

[julienp]

I am not much of a Windows user, from what I remember, I was able to reproduce this on a Windows (11 I think?) VM in Azure, not using WSL, no special config on the VM. We had at least 2 Pulumi users report an issue, where we narrowed down the root cause to this issue.

I don't know how the Volta shims work, but I guess when running under WSL it's doing an exec syscall, but on plain Windows it will have to do something more intricate I believe?

[charlespierce]

Thanks for the reports, and the environment investigation! I suspect this might be related to the fact that we use cmd /C to execute the shimmed packages—I wonder if there's some strange argument handling there that is making it not parse correctly. I do a lot of my individual development on Windows, so should be able to investigate this weekend.

[charlespierce]

Didn't get to investigating that weekend 😅 However just now I did confirm, and from some digging online, I think this might be a hard limitation of cmd.exe, which we use internally to handle resolving executables on Windows.

However, as mentioned in my most recent comment on #1761, that PR may provide a path forward to removing that use of cmd.exe entirely, which would (hopefully) resolve this in passing. I'm hoping to get an investigatory PR up that does that sometime today, though my flight is landing so I may run out of time!