Re: quotearg.c's shell_quoting_style and MinGW

[Paul Eggert]

On 05/06/2012 10:29 AM, Bruno Haible wrote:

> > This would add (by my count) 72 source files to diff
>
> So what? It is no maintenance burden, because "gnulib-tool --update"
> does all a maintainer needs.

Yes and no.  gnulib-tool imports the files automatically,
but the maintainer still needs to deal with the burden of
people sending in bug reports about the added files and so
forth.  The extra files introduce other minor hassles such as
'grep -r' producing unwanted matches.  None of these problems are
enormous, but they are burdens, and I'd rather avoid them
if possible.

Let's put it this way.  diffutils proper has only 77 source
files total.  This includes everything: C files,
documentation, makefiles, etc.  Adding 72 files seems
a bit much just to solve a simple quoting problem.

> > I don't see how these changes would benefit Unix performance.
>
> For src/util.c you are right. But in src/diff3.c and src/sdiff.c, popen()
> is invoked,

Sorry, there still seems to be a misunderstanding here.
In src/diff3.c the pattern is this:

   #if HAVE_WORKING_FORK
     ...
   #else
     ...
     fpipe = popen (command, "r");
     ...
   #endif

which means that popen is not invoked on Unix.  src/sdiff.c is similar.
The popen code is intended only to be executed on non-POSIXish
systems, so worries about efficiency on Unix seem to be misplaced.

I should mention that the popen code does have the nice
property that it can be easily *tested* on POSIXish systems,
simply by compiling with HAVE_WORKING_FORK set to 0, and
this is something I want to retain as much as possible.

> OK, then the code structure you would like to have is
>
>    #if HAVE_WORKING_FORK
>      (code for Unix)
>    #else
>      (prepare arguments)
>      #if (defined _WIN32 || defined __WIN32__)&&  !defined __CYGWIN__
>      (quote the arguments the Windows way, case b)
>      #endif
>      (invoke popen or system)
>    #endif
>
> Is that right?

No, the code structure I'd like in util.c, diff3.c and
sdiff.c is exactly what's there now.  Zero changes there.

> popen() takes a POSIX sh command as argument, possibly with function
> definitions, loops, redirections, and what else. You want code that
> rewrites that into a cmd.exe command?

No, I don't want that.  All we need is code that redoes POSIX
shell quoting into quoting suitable for mingw.

We don't need a complete popen implementation -- all we need is
a popen implementation that's good enough to satisfy our
porting needs.  This is a common situation in gnulib.