From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im> |
Cc: | Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_regress: lookup shellprog in $PATH |
Date: | 2022-08-25 02:30:56 |
Message-ID: | 1324627.1661394656@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Given the lack of complaints about how pg_ctl works, I'd be inclined
> to follow its lead and just hard-wire "/bin/sh", removing the whole
> SHELLPROG/shellprog dance. I have not heard of anyone using the
> theoretical ability to compile pg_regress with some other value.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-08-25 02:47:27 | Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back) |
Previous Message | Tom Lane | 2022-08-25 02:14:24 | Re: pg_regress: lookup shellprog in $PATH |