Ok, I see a problem. Before fastchess could execute a program if it were in your working directory like "-engine cmd=foo". Now we need to do "-engine cmd=./foo". This is what I would expect if I ran fastchess for the first time, but maybe this breaks some configs.

@Disservin do you know why this test on MacOS is failing suddenly? Is posix_spawn implemented differently to posix_spawnp? What is happening?

mh not too sure.. could be another flaw of the mac impl of posix_spawn_file_actions_addchdir_np.. I actually wonder what cutechess does, does cutechess allow engines to be started from path? Maybe edit the ci workflow to output the entire stdout for macos to help debug this

Cutechess only starts engines from path, not from your current directory. So the "opposite" of what fastchess does.

I don't know how MacOS works, but the problem only seems to be that we have a test case where a script does not contain a shebang. This script still manages to run, as if it had a shebang, on MacOS. But why worry about this? We should not author how the OS starts binaries/scripts?

I think this test case should just be removed... It seems very weird that for fastchess to run on an OS, that OS must refuse to launch scripts without a shebang.

Well the unit test caught a difference in behavior now, where on macOS a command works which doesn't on linux.. I assume the implementations slightly differs and that macOS uses

https://man7.org/linux/man-pages/man3/execvp.3.html

p - execlp(), execvp(), execvpe()

If the header of a file isn't recognized (the attempted execve(2)
failed with the error ENOEXEC), these functions will execute the
shell (/bin/sh) with the path of the file as its first argument.
(If this attempt fails, no further searching is done.)

And the other use

https://man7.org/linux/man-pages/man2/execve.2.html

Interpreter scripts
An interpreter script is a text file that has execute permission
enabled and whose first line is of the form:
#!interpreter [optional-arg]
The interpreter must be a valid pathname for an executable file.

Or something like that

Gonna check this myself soon

Given the amount of issues I had in #872 I will probably stick with the posix spawn approach and try to add a fallback here which tries to add ./ in front if the execution failed to match the old behavior?