bug-gnulib
[Top][All Lists]
Advanced

[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 19:29:22 +0200
User-agent: KMail/4.7.4 (Linux/3.1.10-1.9-desktop; KDE/4.7.4; x86_64; ; )

Hi Paul,

> >     use the gnulib modules 'execute' and 'spawn-pipe'....
> 
> 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.

> >       - If you apply these changes also to the HAVE_WORKING_FORK code 
> > branch,
> >         it will speed up the subprocess invocation also on Unix, by
> >         bypassing /bin/sh.
> 
> /bin/sh is already bypassed on Unix, since the code invokes execvp
> or execl in that case, so 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, which invokes a shell, and that shell will immediately
fork() and exec() again to execute the 'diff' program.

> The motivation for the existing code is to have something that is
> simple and easy to understand in portable terms and works
> efficiently on GNU and similar systems, and to do something
> similar (though efficiency is less of a concern) on systems that
> lack 'fork'.  These other systems include not just Microsoft
> Windows, but also other platforms such as OpenVMS.

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?

> What about the other idea, to add gnulib support for popen and for
> system to have them quote properly for mingw?  That would require
> no changes to diffutils proper (other than a one-line addition to
> bootstrap.conf) and would presumably need far fewer than 72 source
> files.

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? This cannot be done in less
than a man-year, and will likely also require more than 72 source files.

What is, more generally, on Unix, the advantage of using system()/popen()
rather than the lower-lever, more efficient exec*/spawn-pipe?
It is that you can easily add more complex commands, with redirections,
logging, reference to environment variables, and such. This is useful
for a program that is in rapid active development. But even in such a
case, the commands are in sh syntax. Complex commands, redirections,
logging, reference to environment variables, etc. all have a different
syntax with cmd.exe. So the maximum gnulib can reasonably offer is that
the author of the code writes two variants of the command, one in sh
syntax and one in cmd.exe syntax.

For this reason, I think it may be useful in gnulib to have a Windows-
specific argument quoting function. It has to be Windows specific, since
you mention OpenVMS and I certainly won't wrote VMS specific code again.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]