Re: quotearg.c's shell_quoting_style and MinGW

[Bruno Haible]

Paul Eggert wrote:
> The idea here is not to reimplement popen from scratch in gnulib,
> or to have gnulib popen support every feature that POSIX requires.
> The idea is only to have a popen wrapper that works assuming that
> its argument is quoted for the POSIX shell, using quotearg.
> Such arguments have a simple format that can easily be converted
> to mingw shell format.  Once this simple conversion is done, the
> wrapper call the real mingw popen.

Whereas my proposal is to provide a windows_cmd_quote function similar
to the shell_quote function, for use with popen() or system() on
native Windows.

Your proposal has the following drawbacks:

  * Like Eli said, a popen() or system() override is going to break
    programs that have already constructed the command line for Windows.

    (Similar to what we experience with the socket functions override
    that take an 'int' file descriptor instead of a 'HANDLE': It broke
    parts of GNU clisp, because clisp uses some native Windows API in
    some corners and gnulib code in other places.)

  * A program like 'diff3' would construct a POSIX sh command to just
    immediately afterwards parse it and decompose it. It is an inefficient
    way of passing arguments. A simple array argv[] of unquoted strings
    is way more efficient.

  * The popen() and system() functions would only understand a limited
    subset of the set of possible sh commands. No specific error code
    exists to signal to the caller such a syntax violation. If a developer
    adds " 2>&1 | tee /tmp/log" to such a command and it doesn't work,
    how will he be notified of his mistake?

    Whereas in a function that takes an array of strings as arguments,
    the limits are evident from the API.

Each of these drawbacks is not severe. But can we avoid them nevertheless?

Whereas for my proposal I see the following drawbacks:

  * The programmer has to explicitly write code with #if for native Windows.

Bruno