Hello, I'm reporting a problem with the execve(2) man page (see the "absolute pathname" part): > If the pathname argument of execve() specifies an interpreter > script, then interpreter will be invoked with the following > arguments: > > interpreter [optional-arg] pathname arg... > > where pathname is the absolute pathname of the file specified as > ^^^^^^^^^^^^^^^^^ > the first argument of execve(), and arg... is the series of > words pointed to by the argv argument of execve(), starting at > argv[1]. Note that there is no way to get the argv[0] that was > passed to the execve() call. Then in the final example: > $ ./execve ./script > argv[0]: ./myecho > argv[1]: script-arg > argv[2]: ./script > argv[3]: hello > argv[4]: world According to the description, argv[2] is supposed to be the *absolute pathname* of "./script" but it is not. (In path_resolution(7), an absolute pathname is defined to be a pathname starting with a '/' character.) I tested the example with kernel 4.4.246 and the output is the same as the one in the man page (relative paths are preserved). I don't know about newer kernels, but if I understand correctly, either the "absolute pathname" wording is incorrect or the example is. (In the latter case, perhaps the man page could also mention the change in behavior.) The "absolute pathname" wording was introduced here: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=60f16bf2fe6bd2d2d001d0a41936e778b1e7e3f6 https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=63059c4b527d0da73666da5ff29dcc902e219371 Regards, NP
