Closed chicoxyzzy closed 4 months ago
Could a way of checking the environment variables independently of the operating system be by introducing either a flag or command to return the environment variables that the CLI has access to?
This means you don't have to worry about if Microsoft changes their commands, and guarantees that the environment variables returned are the same ones that the command actually has access to. A flag would allow it to be used with any of the commands so that you can still test the run command
.
Could a way of checking the environment variables independently of the operating system be by introducing either a flag or command to return the environment variables that the CLI has access to?
This means you don't have to worry about if Microsoft changes their commands, and guarantees that the environment variables returned are the same ones that the command actually has access to. A flag would allow it to be used with any of the commands so that you can still test the
run command
.
Yes, I was thinking about that. For now I'm going to disable these tests on Windows and work on enabling them in a next PR
@chriso please let me know if I should do something to kill all the processes on Windows similar to how it's done for linux and darwin.
@achille-roussel not sure how to use run_unix.go
, it says
killProcess redeclared in this block (see details) [windows]
...so I reuse the same code in run_linux.go
and run_darwin.go
here
The reason we use the lower level syscall.Kill
for Linux/macOS is because it lets us pass a negative PID, which sends the signals to all processes in the process group we create (via SysProcAttr.Setpgid
) when spawning the local application.
The higher level cmd.Process.Kill()
is equivalent to syscall.Kill(cmd.Process.Pid, syscall.SIGKILL)
on these platforms, which sends the signal to the process rather than the process group.
I'm not familiar with Windows syscalls so I'm not sure how to accomplish the same thing there. Windows may not even have the concept of process groups. I think what you've done here – default to using cmd.Process.Kill()
– is the right approach for now :+1: We can figure out a better strategy for Windows later if/when necessary.
We should use something platform-independent instead of
printenv
. I'm going to work on this in another PR