On Thu, Aug 25, 2022 at 04:04:39PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Aug 25, 2022 at 10:48 AM Tom Lane wrote:
> >> If we were executing a program that the user needs to have some control
> >> over, sure, but what we have here is an implementation detail that I
> >> doubt
Robert Haas writes:
> On Thu, Aug 25, 2022 at 10:48 AM Tom Lane wrote:
>> If we were executing a program that the user needs to have some control
>> over, sure, but what we have here is an implementation detail that I
>> doubt anyone cares about. The fact that we're using a shell at all is
>>
On Thu, Aug 25, 2022 at 10:48 AM Tom Lane wrote:
> If we were executing a program that the user needs to have some control
> over, sure, but what we have here is an implementation detail that I
> doubt anyone cares about. The fact that we're using a shell at all is
> only because nobody has
Robert Haas writes:
> I mean, I can see you're on the warpath here and I don't care enough
> to fight about it very much, but as a matter of theory, I believe that
> hard-coded pathnames suck. Giving the user a way to survive if /bin/sh
> doesn't exist on their system or isn't the path they want
On Thu, Aug 25, 2022 at 10:13 AM Tom Lane wrote:
> My point is that that *isn't* what POSIX specifies. They say in so
> many words that the path actually used by system(3) is unspecified.
> They do NOT say that it's the value of $SHELL, and given that you're
> allowed to set $SHELL to a
Robert Haas writes:
> 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);
Right. I wouldn't
On Wed, Aug 24, 2022 at 10:31 PM Tom Lane 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(, "sh", "-c", command,
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
Gurjeet Singh writes:
> Please see attached the one-letter patch that fixes this problem. I have
> chosen to replace the execl() call with execlp(), which performs a lookup
> in $PATH, and finds the 'sh' to use for running the postmaster.
I can't say that I think this is a great fix. It creates
I'm trying to build Postgres using the Nix language and the Nix package
manager on macOS (see [1]). After some work I was able to build, and even
run Postgres. But `make check` failed with the error
pg_regress: could not exec "sh": No such file or directory
The reason is that pg_regress uses
10 matches
Mail list logo
