Date: Sat, 9 May 2020 13:00:54 +0000 (UTC)
From: shwaresyst <shwares...@aol.com>
Message-ID: <600759678.614717.1589029254...@mail.yahoo.com>
| Just floating this out there... While a posix_spawnp() kernel imp doing
| PATH searches relative to the parent's pwd is a well defined behavior,
I think you misunderstood:
casper....@oracle.com said:
| The PATH being searched is not necessarily the same PATH in the child
| process but that of the parent.
What that refers to is the value of $PATH from the parent, not the
parent's PWD. If it was intended to work as you suggest there, there
would be much less of an issue (the chdir fileactions would be irrelevant,
and posix_spawnp with them would be the same as without them).
| should there be an additional file_action that search for the
| executable happens after the chdir action;
Since the file actions happen before the PATH search for the exec,
that is the natural (and I believe, expected) behaviour of the
current chdir and fchdir file actions.
That's what makes them evil to implement in kernel implementation
of posix_spawn where the path search for posix_spawnp is to be in
user code (where it belongs).
| for the case where PATH, as inherited by the child environment,
The PATH in the child environment seems to be irrelevant (other
than that is what the child, once it is running, sees).
| has "./" or "../" as initial element of a PATH entry?
You mean any relative path (anything that does not start with a '/').
There doesn't have to be a '.' to get a PWD relative path (though that
is certainly one way).
kre
