On Thu, Aug 25, 2022 at 04:04:39PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Aug 25, 2022 at 10:48 AM Tom Lane <tgl@sss.pgh.pa.us> 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 cared to manually implement I/O redirection logic
> >> in these places; otherwise we'd be execl()'ing the server or psql directly.
> >> Maybe the best answer would be to do that, and get out of the business
> >> of knowing where the shell is?
> The Windows side of this is completely untested and may be broken; also,
> perhaps Windows has something more nearly equivalent to execvp() that we
> could use instead of reconstructing a command line? It's annoying that
Windows has nothing like execvp(), unfortunately.
> the patch removes all shell-quoting hazards on the Unix side but they
> are still there on the Windows side.
It's feasible to take cmd.exe out of the loop. One could then eliminate
cmd.exe quoting (the "^" characters). Can't avoid the rest of the quoting
(https://docs.microsoft.com/en-us/cpp/cpp/main-function-command-line-args#parsing-c-command-line-arguments).
Bypassing cmd.exe would also make it easy to remove the ban on newlines and
carriage returns in arguments.
