Add some utilities for PATH searching.#2405
Open
3405691582 wants to merge 1 commit intogoogle:mainfrom
Open
Conversation
Databean
approved these changes
Apr 16, 2026
Member
Databean
left a comment
Databean
left a comment
There was a problem hiding this comment.
I'm not sure we can use posix_spawn because we do a bunch of work between the fork and exec steps, though some of that is also linux-specific.
Definitely regret the change to use execvpe over execve, which came in aosp/1584808, and would prefer to use execve again though I don't know how much other fallout it would cause.
GoogleCuttlefishTesterBot
removed
the
kokoro:force-run
A lot of our tooling relies on executing binaries found on the host system. The subprocess library ends up calling execvpe on Linux, which means that PATH resolution happens for the executable. Two issues present themselves. Firstly, execvpe is a Linuxism -- it is not in the SUS; our tentative non-Linux (macOS) implementation calles execve instead. Secondly and more importantly, if the executable that we expect to be able to run is not in PATH, then we will fail to exec it, even if the actual executable is installed; this can happen on some distributions where nonprivileged users are configured by default to not have executables where root privileges are required in PATH. Therefore, we need to be able to perform PATH resolution ourselves, so that we can do things like test if a binary truly isn't available or whether it merely isn't in the current PATH. We add a reminder for ourselves too that while the usual colon-separated PATH splitting makes perfect sense for SUS systems, it is not the case on platforms like Windows -- if in the future we want to go down that direction. (Also, perhaps we should just migrate to using posix_spawn, but that's not important right now.) Bug: 488432653
GoogleCuttlefishTesterBot
removed
the
kokoro:force-run
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A lot of our tooling relies on executing binaries found on the host system. The subprocess library ends up calling execvpe on Linux, which means that PATH resolution happens for the executable.
Two issues present themselves. Firstly, execvpe is a Linuxism -- it is not in the SUS; our tentative non-Linux (macOS) implementation calles execve instead.
Secondly and more importantly, if the executable that we expect to be able to run is not in PATH, then we will fail to exec it, even if the actual executable is installed; this can happen on some distributions where nonprivileged users are configured by default to not have executables where root privileges are required in PATH.
Therefore, we need to be able to perform PATH resolution ourselves, so that we can do things like test if a binary truly isn't available or whether it merely isn't in the current PATH.
We add a reminder for ourselves too that while the usual colon-separated PATH splitting makes perfect sense for SUS systems, it is not the case on platforms like Windows -- if in the future we want to go down that direction.
(Also, perhaps we should just migrate to using posix_spawn, but that's not important right now.)
Bug: 488432653