Re: [bug-gnulib] system module?

[Eric Blake-1]

> 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.