Re: [bug-gnulib] system module?

[Bruno Haible]

Eric Blake asked:
> Is it worth adding a system module to gnulib that detects implementations 
> with 
> this bug, and provides rpl_system to work around it?

The specification of system() in ISO C 99 does not specify
  1) which is the command processor,
     and in particular which are the built-in commands and how to quote
     arguments when constructing a program incovcation with arguments,
  2) how the command is executed (in particular, the signal handling),
  3) the return value semantics.

Andreas Büning asks about the third problem, but the first and second are
more important.

Because of 1), I don't think it would be useful for gnulib to provide a
substitute. When a programmer uses the system() command, you don't know
whether he intends to invoke the system's command processor or a /bin/sh
implementation. On Windows: cmd.exe or /bin/sh? On VMS: DCL or sh?
gnulib makes it easy to invoke /bin/sh on all platforms:
  execute ("sh", "/bin/sh", { "/bin/sh", "-c", command, NULL }, ...)
We cannot provide portability aids for programmers who want to use
cmd.exe or DCL.

Witness of this: GNU clisp offers facilities for invoking programs and
executing commands, but does not use system(). IIRC, it used system()
15 years ago, but
  1) the confusion between COMMAND.COM and CMD.EXE on DOS and Windows,
     as well as the weird argument quoting rules on Windows, that are
     different in CMD.EXE than in CreateProcess,
  2) the signal handling on SVR4 systems,
     and some additional problem with file descriptors in EMX system(),
made it unpractical to continue using system(). (I don't remember the
details, sorry.)

Bruno