Why is findExecutables private?

[evancz]

Context: I am working on a tool like git such that git hats actually routes the user to an executable named git-hats. One nice feature provided by git is that they will list all of the commands available on your system, even if they are not distributed with git. This means figuring everything on the user's PATH and filtering it down to things that match git-*.

My case described here is pretty much exactly the same, and I need the functionality of findExecutables to make it happen.

Question: Is there a strong reason findExecutables (implemented here) is not exposed? If so, would you recommend duplicating the code? If so, what is going on with the mingw32_HOST_OS macros? Do I need to do any special configuration to use macros like that?

[hvr]

findExecutables was added as part of 7789d1c (see also GHC #2184) with other functions, but for some reason wasn't exposed.

At this point, this probably just needs to be blessed by the @haskell/core-libraries-committee

[nomeata]

@evancz: For the case of a git list like feature, findExecutables won’t help you: It still wants you to specify the full name of the executable.

[evancz]

Ah, I see that now. Is there something that will help me?

It looks like it's plausible to do what I want on UNIX, maybe using getDirectoryContents with some snippets from findExecutables. But it's very not clear to me how things would work on Windows. Do you know that this can be done? If so, how can I learn more or find a library for this. If not, is this an ability that Haskell should have and how do we get there?

[snoyberg]

Following our (seemingly accepted) new principle of just getting things done: I've pushed a commit that exposes findExecutables. I'll leave this issue open for (1) the other conversation, and (2) in case someone wants to tar and feather me :)

[nomeata]

I don’t want to tar and feather you, but given that this does not actually help with @evancz issue, and I’m not sure what other uses cases there are, I don’t think there is much point in exporting this function. It will just cause confusions for users, thinking “what is that for?” when they read through the docs.

[snoyberg]

As I see it:

1. It's a function that may be useful in other circumstances. I could easily see myself wanting this function to, e.g., discover all the different ghcs on my $PATH.
2. It seems like it was a mistake to not expose it previously, as it was merged in with seeming intention to export it. I see this as a pretty straightforward bugfix.

The argument of "could confuse people" implies that we should never add functions that some users may not want.

[nomeata]

Looks like you found a use case (although maybe a bit hypothetical), so I concur ;–)

[hvr]

well, the "could confuse people" part could be addressed by improving the documentation... :)

[Rufflewind]

It looks like it's plausible to do what I want on UNIX, maybe using getDirectoryContents with some snippets from findExecutables. But it's very not clear to me how things would work on Windows. Do you know that this can be done?

On Windows (specifically non-Cygwin), you should inspect the PATH environment variable, split it by semicolon (;) and look for anything that ends in .exe. Of course, there are other kinds of executables on Windows as well (such as .bat) but they are fairly rare.

[Rufflewind]

Closing since the original issue has been resolved.