On Thu, Aug 25, 2022 at 04:04:39PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Aug 25, 2022 at 10:48 AM Tom Lane <t...@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.
