This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: execlp/execvp/execvpe behavior change in glibc 2.24?
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 20 Nov 2017 13:54:18 -0200
- Subject: Re: execlp/execvp/execvpe behavior change in glibc 2.24?
- Authentication-results: sourceware.org; auth=none
- References: <06686c46-9ad5-779c-76dc-108f26e6ea40@gmail.com>
On 20/11/2017 12:56, Michael Kerrisk (man-pages) wrote:
> 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.
I am trying to recall if this specific change was really intentional,
but nothing special come to my mind and checking review thread also
does not help much.
>
> 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?
Review it I also agree this seems beneficial and POSIX states
this special case is implementation-defined. I also do not oppose
if this might characterize as compat issue and we should go back
to old behaviour. Thoughts?