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

How to resolve "prog" in PATH? #5

Open
vog opened this issue May 10, 2018 · 2 comments
Open

How to resolve "prog" in PATH? #5

vog opened this issue May 10, 2018 · 2 comments

Comments

@vog
Copy link

vog commented May 10, 2018

The documentation in spawn.mli says:

[prog] is not searched in [PATH]. It is up to the caller to do the path resolution before calling this function.

However, it does not explain how the caller is expected to do that.

There are perhaps many ways to achieve in OCaml, nevertheless I propose that the documentation briefly mentions which method the library author(s) had in mind, and/or which method they are actually using when faced with that task.

Even better would be an actual helper function to resolve that, e.g.

spawn ... ~prog:(resolve_path prog_name) ...
@ghost
Copy link

ghost commented May 10, 2018

The idea is that spawn is a minimalist library that only exposes an efficient and complete primitive for starting processes. complete in the sense that it exposes all the options one might want, such as setting the cwd. In practice, this is very tedious to get right, especially since spawn uses vfork when possible.

Higher level functions are left to third-party libraries. For instance core or shexp have such functions.

That said, I personally wouldn't object to adding Spawn.resolve_program.

@aalekseyev
Copy link
Contributor

If considering this one should keep in mind that there are two main approaches:

  • resolve path and then call spawn once, how shexp does it
  • attempt spawn on all candidate paths until one of them succeeds, how core and glibc do it.

The latter approach is less racy, but it is slower.

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

No branches or pull requests

2 participants