which() should check executability before returning a value

[nfischer]

which() should only return a value if it finds a matching file in the PATH and that file is executable.

I'm not sure if it's possible to reliably check executability on Windows, but this should at least be done for unix. This section of the docs suggests a way of using fs.statSync() to check this info.

The right way would be to also check if the current user matches the user, group, or all fields as well, but I think this might be tricky. It should be sufficient to just assume that we do have a match, and just do an OR of all three (ex. userCanExecute() || groupCanExecute() || allCanExecute()).

[nfischer]

@termosa, if you're interested in taking this up in a new PR after #655 is merged, just ping this thread to let me know you're working on it. Otherwise I'll take it up.

[termosa]

@nfischer I updated #655 with fixes.
This issue is interesting and can be incredibly useful in specific cases. But still I want to ask you: Are you sure you want to apply it to the which function and change its default behavior?

[nfischer]

Are you sure you want to apply it to the which function and change its default behavior?

From the docs:

Searches for command in the system's PATH.

To me, "command" implies something which can be executed. Therefore, it's a bug to point to something which cannot be executed (but, as noted above, Windows and Unix have different definitions of "executability", and we need to make the right decision for each OS).

---

To examine this another way, imagine your $PATH is ~/first-folder:~/second-folder, and you have the following:

$ ls -l ~/first-folder/foo ~/second-folder/foo
-rw-r----- 1 [...] ~/first-folder/foo
-rwxr-x--- 1 [...] ~/second-folder/foo
$ foo # executes second-folder/foo, because first-folder/foo lacks exec bit
$ which foo # if this returns first-folder/foo, that would be a bug
~/second-folder/foo

[termosa]

@nfischer OK. I'll send you PR soon.