[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: quotearg.c's shell_quoting_style and MinGW
From: |
Bruno Haible |
Subject: |
Re: quotearg.c's shell_quoting_style and MinGW |
Date: |
Sun, 06 May 2012 20:33:05 +0200 |
User-agent: |
KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; ) |
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
- Re: quotearg.c's shell_quoting_style and MinGW, (continued)
Re: quotearg.c's shell_quoting_style and MinGW, Paul Eggert, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Eli Zaretskii, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Paul Eggert, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Eli Zaretskii, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Paul Eggert, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Eli Zaretskii, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Paul Eggert, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW,
Bruno Haible <=
- Re: quotearg.c's shell_quoting_style and MinGW, Bruno Haible, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Paul Eggert, 2012/05/06
- Re: quotearg.c's shell_quoting_style and MinGW, Bruno Haible, 2012/05/06
Re: quotearg.c's shell_quoting_style and MinGW, Eli Zaretskii, 2012/05/06
Re: quotearg.c's shell_quoting_style and MinGW, Bruno Haible, 2012/05/06
Re: quotearg.c's shell_quoting_style and MinGW, Eli Zaretskii, 2012/05/06
Re: quotearg.c's shell_quoting_style and MinGW, Bruno Haible, 2012/05/06
new module 'system-quote', Bruno Haible, 2012/05/08
Re: new module 'system-quote', Bruno Haible, 2012/05/08
Re: new module 'system-quote', Eli Zaretskii, 2012/05/09