You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
os/exec.LookPath contains robust logic for looking up paths cross-platform. However, it is always based on the value of the PATH environment variable; there are cases where one might like to employ the same logic but using a PATH that has come from elsewhere. My current motivating example relates to remote build execution where it may be based on an incoming RPC, I expect others to exist in the wild as well.
In terms of prior art, this seems a little similar to os.Expand and os.ExpandEnv which offer the same option of using the environment or not. We can't match the naming convention of those though so the best suggestion I have is exec.LookPathFrom(file, path string) (string, error).
I anticipate the implementation of this being straightforward, and it shouldn't represent significant additional maintenance in future. I'm of course happy to raise the PR if this proposal is accepted.
Alternatives
In the absence of this function, one could set the PATH variable to the desired value, use LookPath, then reset it back again. This is slightly more work but more importantly is mutating global process state, and is therefore not safe to use if multiple goroutines might execute the same code concurrently.
Possibly a more likely solution is that you'd write some code to do this yourself. That isn't so hard on the face of it, but looking at the actual implementation in exec, it seems unlikely that most implementations would be diligent enough to mimic all the cross-platform nuances or the various edge/error cases that are checked. It would of course also be nice to get updates or fixes to it as well (the command path security changes from 1.19 would be a good example of that).
The text was updated successfully, but these errors were encountered:
Apologies, I did not find those issues when opening this.
I guess that I have nothing new. I will simply reiterate dissatisfaction with the previous reasoning for rejecting this - the existing code is several hundred lines across 4 files (plus 4 more for tests), I think it's disingenuous to write that off as "it's easy to copy". As I tried to outline before, it seems unlikely to me that a copy would keep all the nuance (am I going to copy and maintain a file for plan9 which I'll never use and have no way of testing?) or keep up with updates, and the cost of adding this seems to me to be low.
This is something I needed in different projects (eg: direnv, treefmt). It makes it easier to execute programs in different folders and context, without changing the whole program's Cwd. Not depending on globals also makes it easier to run unit tests.
os/exec.LookPath
contains robust logic for looking up paths cross-platform. However, it is always based on the value of thePATH
environment variable; there are cases where one might like to employ the same logic but using aPATH
that has come from elsewhere. My current motivating example relates to remote build execution where it may be based on an incoming RPC, I expect others to exist in the wild as well.In terms of prior art, this seems a little similar to
os.Expand
andos.ExpandEnv
which offer the same option of using the environment or not. We can't match the naming convention of those though so the best suggestion I have isexec.LookPathFrom(file, path string) (string, error)
.I anticipate the implementation of this being straightforward, and it shouldn't represent significant additional maintenance in future. I'm of course happy to raise the PR if this proposal is accepted.
Alternatives
In the absence of this function, one could set the
PATH
variable to the desired value, useLookPath
, then reset it back again. This is slightly more work but more importantly is mutating global process state, and is therefore not safe to use if multiple goroutines might execute the same code concurrently.Possibly a more likely solution is that you'd write some code to do this yourself. That isn't so hard on the face of it, but looking at the actual implementation in
exec
, it seems unlikely that most implementations would be diligent enough to mimic all the cross-platform nuances or the various edge/error cases that are checked. It would of course also be nice to get updates or fixes to it as well (the command path security changes from 1.19 would be a good example of that).The text was updated successfully, but these errors were encountered: