On Wed, Aug 24, 2022 at 10:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> git blame blames that whole mechanism on me: 60cfe25e68d. It looks
> like the reason I did it like that is that I was replacing use of
> system(3) with execl(), and system(3) is defined thus by POSIX:
>
> execl(<shell path>, "sh", "-c", command, (char *)0);
>
> where <shell path> is an unspecified pathname for the sh utility.
>
> Using SHELL for the "unspecified path" is already a bit of a leap
> of faith, since users are allowed to make that point at a non-Bourne
> shell. I don't see any strong reason to preserve that behavior.
It seems weird that you use any arbitrary shell to run 'sh', but I
guess the point is that your shell command, whatever it is, is
supposed to be a full pathname, and then it can do pathname resolution
to figure out where you 'sh' executable is. So that makes me think
that the problem Gurjeet is reporting is an issue with Nix rather than
an issue with PostgreSQL.
But what we've got is:
[rhaas pgsql]$ git grep execl\(
src/bin/pg_ctl/pg_ctl.c: (void) execl("/bin/sh", "/bin/sh", "-c", cmd,
(char *) NULL);
src/test/regress/pg_regress.c: execl(shellprog, shellprog, "-c",
cmdline2, (char *) NULL);
And surely that's stupid. The whole point here has to be that if you
want to run something called 'sh' but don't know where it is, you need
to execute a shell at a known pathname to figure it out for you.
We could do as you propose and I don't think we would be worse off
than we are today. But I'm confused why the correct formulation
wouldn't be exactly what POSIX specifies, namely execl(shellprog,
"sh", "-c", ...). That way, if somebody has a system where they do set
$SHELL properly but do not have /bin/sh, things would still work.
--
Robert Haas
EDB: http://www.enterprisedb.com