This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
execlp/execvp/execvpe behavior change in glibc 2.24?
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: adhemerval dot zanella at linaro dot org
- Cc: mtk dot manpages at gmail dot com, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 20 Nov 2017 15:56:18 +0100
- Subject: execlp/execvp/execvpe behavior change in glibc 2.24?
- Authentication-results: sourceware.org; auth=none
Hello Adhemerval,
Your commit
commit 1eb8930608705702d5746e5491bab4e4429fcb83
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date: Fri Jan 22 09:58:49 2016 -0200
posix: execvpe cleanup
Appears to have caused a behavior change in execlp/execvp/execvpe,
and I am wondering whether it was intentional.
In glibc 2.23 and earlier, if PATH was undefined, then the default
path search list that was used included the current working
directory as the first entry.
if (path == NULL)
{
/* There is no `PATH' in the environment.
The default search path is the current directory
followed by the path `confstr' returns for `_CS_PATH'. */
path = name + pathlen + len + 1;
path[0] = ':';
(void) confstr (_CS_PATH, path + 1, pathlen);
}
Starting in glibc-2.24, we have:
const char *path = getenv ("PATH");
if (!path)
path = CS_PATH;
and
#define CS_PATH "/bin:/usr/bin"
This excludes the CWD from the list. And testing seems to
confirm this.
I consider the change beneficial actually, since including
the CWD in the default search path does seem risky.
However, I see no mention in the commit message about this
behavior change, nor could I see anything in NEWS. So, I
wonder, was the change intended?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/