> 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.
But POSIX specifies all three points, so when implementing a POSIX version of m4, it would be nice to rely on POSIX semantics of system(). I thought one of gnulib's goals was to provide useful POSIX semantics atop non-POSIX systems, where possible. Also, C99 does not specify popen()/pclose(), but POSIX does. m4 has been using system() to implement syscmd, and popen() to implement esyscmd(). If system() is not worth using, then it is likely that popen() should not be used, either. > > Andreas Büning asks about the third problem, but the first and second are > more important. Actually, Andreas was reporting that WEXITSTATUS was returning the wrong value. But I just checked a mingw implementation (actually, used the cygwin compiler in cross-compilation mode by using -mno-cygwin), and found that popen() and system() are consistent - the return value is in the lower 8 bits. And based on this message, http://gcc.gnu.org/ml/fortran/2005-05/msg00225.html, mingw still does not provide WEXITSTATUS in its headers (there is no <sys/wait.h>, and <stdlib.h> does not provide them), so my fallback definitions of WEXITSTATUS (as recommended by the autoconf manual under AC_CHECK_SYS_WAIT) were used instead, explaining why it was grabbing the wrong 8 bits. If mingw had instead provided WEXITSTATUS that grabbed the low 8 bits, similar to BeOS, then this might have been a non-issue. I have yet to get an answer from Andreas whether system() and pclose() are consistent on OS/2, as they are on mingw, and whether his system headers define WEXITSTATUS anywhere. That thread means that the autoconf decision to obsolete AC_HEADER_SYS_WAIT for 2.60 may have been premature; at any rate, the documentation under that macro is not completely accurate - I'll have to forward this bug report on to autoconf as well. > > 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. What should m4 do in its syscmd() macro, then? POSIX is clear; if m4 is POSIX-compliant, then it executes the command using the POSIX sh (not necessarily /bin/sh, but that serves as a close approximation). But on non-POSIX platforms, such as mingw or OS/2, should syscmd still expect the user to have /bin/sh available, rather than passing the string to the native shell with all its non-portable quoting? > > 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 -- View this message in context: http://www.nabble.com/system-module--t1820214.html#a5014691 Sent from the Gnulib forum at Nabble.com.
