Re: pg_regress: lookup shellprog in $PATH

Robert Haas <robertmhaas(at)gmail(dot)com> 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 really feel a need to change anything, except
that we have this weird inconsistency between the way pg_ctl does
it and the way pg_regress does it. I think we should settle on
just one way.

> 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.

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.

(It looks like pg_ctl has used /bin/sh since 6bcce25801c3f
of Oct 2015.)

regards, tom lane