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: new function LookPaths #54688

Open
nnzv opened this issue Aug 26, 2022 · 3 comments
Open

proposal: os/exec: new function LookPaths #54688

nnzv opened this issue Aug 26, 2022 · 3 comments
Labels
Milestone

Comments

@nnzv
Copy link

nnzv commented Aug 26, 2022

The name of an executable could be found in different paths (e.g, different versions of the same executable). LookPath is internally used to find what and retrieves something to run. Thus, I don't feel strong to modify what it retrieves to accomplish this purpose.

Instead, I've thought about a new function called LookPaths to give all possible matches of the wanted executable's name rather than the first matched occurrence.

For example, in case want all possible paths of bash:

package main

import (
    "fmt"
    "log"
    "os/exec"
)

func main() {
    path, err := exec.LookPaths("bash")
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println(path)
    // Sample Output: [/bin/bash /usr/bin/bash /usr/local/bin/bash]
}

In regards to an archaic design of LookPaths:

func LookPaths(file string) ([]string, error) { 
    // ...
}
@nnzv nnzv added the Proposal label Aug 26, 2022
@gopherbot gopherbot added this to the Proposal milestone Aug 26, 2022
@seankhliao
Copy link
Member

Are there existing uses of similar functions?
Why should it be in the standard library? https://go.dev/doc/faq#x_in_std
This looks like something that could easily be done in user code

@nnzv
Copy link
Author

nnzv commented Aug 26, 2022

Are there existing uses of similar functions?

As far as I'm concerned, there are not.

Why should it be in the standard library?

The package os/exec should provide a function which seeks and retrieves all possible paths of an executable's name instead of the first encountered. Meaning, flexibility on what we can use to run.

This looks like something that could easily be done in user code

I don't think so. If we adopt that way, user code would be merely a clone of the work done on os/exec, implementing not significant differences.

@golightlyb
Copy link
Contributor

If this proposal is accepted, a variant that ignores relative paths should probably be added to x/sys/execabs too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

4 participants