Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: os/exec: Provide generalized version of exec.LookPath #59753

Closed
oakad opened this issue Apr 21, 2023 · 3 comments
Closed

proposal: os/exec: Provide generalized version of exec.LookPath #59753

oakad opened this issue Apr 21, 2023 · 3 comments

Comments

@oakad
Copy link

oakad commented Apr 21, 2023

Deciding, whether a particular file can be executed is a surprisingly convoluted problem, as evident from the implementation of exec.LookPath feature. In some cases, particularly when working on various tooling, we want to locate an executable not on the default system path, but elsewhere. Even more so, there may exist several executables, of which some may be preferred over others, due to version and other such considerations.

Therefore, I would like to propose to leverage the platform specific mechanics of exec.LookPath via a companion function:

func FindExecutable(exeName string, possibleLocations []string) (found []string)

The proposed function will do almost exactly the same thing as LookPath, but will take a list of directories as an additional argument (as opposed to predefined list in $PATH) and will return all the results instead of just the first encountered.

Implementing such a feature in a user library is cumbersome, because it requires non-trivial platform specific logic, which is already present and tested in os/exec package.

@oakad oakad added the Proposal label Apr 21, 2023
@gopherbot gopherbot added this to the Proposal milestone Apr 21, 2023
@seankhliao
Copy link
Member

Duplicate of #20081

@seankhliao seankhliao marked this as a duplicate of #20081 Apr 21, 2023
@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Apr 21, 2023
@oakad
Copy link
Author

oakad commented Apr 24, 2023

Because of non-sound reason to close 6 years ago no revisiting the issue can ever be considered?

This is a tricky and widely used feature which many people got wrong in their libs.

Kind of similar to the situation with string escaping and unescaping, whereupon public API is much inferior to the internal API, yet can not be exported, because "inferior to the level of non-usability public API is already there".

@ianlancetaylor
Copy link
Contributor

@oakad Do you have new information to add that was not considered in #20081? As it says in that issue, this is a special purpose operation that few people need, and it's easy to copy the standard library code.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants