I'm not sure how, but on my machine, where docker returns C:\Program Files\Docker\Docker\resources\bin\docker, and running this actually does work (it's a shell script. starts with #!/usr/bin/env. I don't have WSL, AFAIK).

So probably add empty string to the list of options?

return $resolved; here

Does where only return that, or are there multiple results? And do you mean running it from the command prompt, or using proc_open() with 'bypass_shell'? I suspect it might actually be executing a docker.exe in the same directory, or something like that.

But if you really can do that with an extension-less file, then I guess I'll need to install Docker and figure out how it does it. If I just allowed files with no extension here, that would break my jshint problem again, so I'd need to find a different solution. (There's an extension-less C:\Users\a\AppData\Roaming\npm\jshint in my case, which is a shell script as well, but it can't be executed.)

It looks like pathinfo(..., PATHINFO_EXTENSION) can be used to get the file's extension. It's not used often in the phorge codebase but it's probably reasonable to use.

It returns both C:\Program Files\Docker\Docker\resources\bin\docker and C:\Program Files\Docker\Docker\resources\bin\docker.exe, when running from command line.

But it's also possible that when I think I'm running C:\Program Files\Docker\Docker\resources\bin\docker, it actually implicitly runs the exe file with the same name - I'll check that more tomorrow (it's the work machine).

does where return the extension-less jshint for you?

Checked on the Windows machine again, and I think where is lying.

I copied docker to docker2, and where docker2 does show it, but trying to execute it days "not recognized as ....", so I it probably not executing the docker file as well.

I ran where /?, and it looks like where isn't even pretending to return "executables" - it "Displays the location of files that match the search pattern. By default, the search is done along the current directory and in the paths specified by the PATH environment variable."
and the examples explicitly show "*.dll" as a reasonable use-case.

So there's probably no reason to add '' to the extensions list.