Robert Elz <[email protected]> wrote, on 06 May 2020: > > | On such a system, presumably posix_spawnp() would be a C > | library function > > Yes, so it is. > > | that calls a posix_spawnp system call passing it the value > | of PATH as an extra argument. > > but no, no thanks, we will not be putting PATH searches into the kernel.
Why so averse to what is obviously the simplest and cleanest solution? The best place to try the different path prefixes is at the place where you actually use the filename, i.e. when you load the new process image from a file. If you don't want to do the string processing in the kernel, then you can have the userland function create an array of pathnames to try loading. (Then posix_spawn() could use the same system call and just pass it an array containing one pathname.) > I have an idea for an implementation method for posix_spawnp() which > might work, and allow even the fchdir "file action" (it isn't really, > chdir is a process action, it just happens to affect path resolution) > to work as well. > > But since we don't have (does anyone) the chdir file actions in the > kernel, those (for just posix_spwan) need to come first, before I can > test whether the technique I think might work is actually implementable. > > That will depend a lot on whether our posix_spawn actually does the > "return error" technique, or the "exit 127" technique on errors - if > it is the latter, then I still see no hope, but if posix_spawn() > doing a return(0) actually means that everything worked, it might be > possible (by simply doing the loop around posix_spawn() calls, modifying > the pathname according to PATH, until one works, or a non path related > error is returned). That approach won't work because it will repeat the list of file actions, some of which might not be idempotent. Also, how would you distinguish between a path related error caused by the attempted image load from one caused by one of the file actions? -- Geoff Clare <[email protected]> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
