Re: pg_regress: lookup shellprog in $PATH - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pg_regress: lookup shellprog in $PATH
Date
Msg-id CA+TgmoaBu7e3kedRF3HFyhm=R5rqcdO1BxZ_ELFzWnUwKm_TUg@mail.gmail.com
Whole thread Raw
In response to Re: pg_regress: lookup shellprog in $PATH  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_regress: lookup shellprog in $PATH
List pgsql-hackers
On Thu, Aug 25, 2022 at 10:13 AM Tom Lane <tgl@sss.pgh.pa.us> 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 non-POSIX-compatible shell, using that
> is really wrong.  We've gotten away with it so far because we
> resolve $SHELL at build time not run time, but it's still shaky.
>
> Interestingly, if you look at concrete man pages, you tend to find
> something else.  Linux says
>
>        The  system()  library  function uses fork(2) to create a child process
>        that executes the shell command specified in command using execl(3)  as
>        follows:
>            execl("/bin/sh", "sh", "-c", command, (char *) 0);
>
> My BSD machines say "the command is handed to sh(1)", without committing
> to just how that's found ... but guess what, "which sh" finds /bin/sh.
>
> In any case, I can't find any system(3) that relies on $SHELL,
> so my translation wasn't correct according to either the letter
> of POSIX or common practice.  It's supposed to be more or less
> a hard-wired path, they just don't want to commit to which path.
>
> Moreover, leaving aside the question of whether pg_regress'
> current behavior is actually bug-compatible with system(3),
> what is the argument that it needs to be?  We have at this
> point sufficient experience with pg_ctl's use of /bin/sh
> to be pretty confident that that works everywhere.  So let's
> standardize on the simpler way, not the more complex way.

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 to use seems
fundamentally sensible to me. Now if system() doesn't do that anyhow,
well then there is no such mechanism in such cases, and so the benefit
of providing one in the tiny number of other cases that we have may
not be there. But if you're trying to convince me that hard-coded
paths are as a theoretical matter brilliant, I'm not buying it.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Next
From: Robert Haas
Date:
Subject: Re: Letter case of "admin option"