-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 6/1/2008 3:58 AM: | What about OSF/1 4.0 and 5.1? On these systems, CONFIG_SHELL gets set to | /bin/ksh. I take this as an indication that /bin/sh is not POSIX conforming | either. The manual pages of system() and popen() don't give an indication | how to influence which shell these functions use.
In one sense, that strengthens the argument for bypassing system()/popen() in favor of executing the shell of choice determined at configure time. In another sense, Solaris advertises that they support POSIX compliance; OSF does not. Building a POSIX-compliant m4 on Solaris should therefore be expected, while building a POSIX-compliant m4 on OSF is a bonus and not standard. | | But when we offer gnulib as a library, some things - like whether to use | XPG4 semantics or not - must remain among the freedom of the user of the | library. All right, I will buy that argument. |> Does the execute module allow distinguishing exits due to signals from |> regular exits? M4 is currently documented as treating the sysval macro |> differently to allow the user to distinguish between signals, but it looks |> like wait_subprocess collapses all non-fatal signals into 127 | | Currently the 'execute' module indeed does not allow to distinguish between | launch failure and fatal signals. I could imagine to provide this info through | an optional parameter. But how do you want to treat the portability problem | to mingw here? mingw doesn't have signals, so the optional parameter would never be populated. | | How does m4 treat mingw at all? Which shell does it use in 'syscmd' and | 'esyscmd'? The m4 documentation currently mentions that syscmd uses whatever system() provides (probably 'cmd.exe /c' for mingw); and that POSIX compliance is only attempted for platforms where the m4 macro __unix__ is defined (mingw defines __windows__, not __unix__). At any rate, on mingw, syscmd is certainly nowhere near a POSIX-compliant command parser, and the m4 testsuite intentionally skips all tests that try to do anything with a shell metacharacter or other action that just won't work without /bin/sh as the interpreter (syscmd still works for some things regardless of shell, such as a recursive invocation of m4 with arguments that do not contain shell metacharacters). |> it looks like execute.c blindly undefines open, but this conflicts with |> "fcntl--.h" from the fcntl-safer module. Does the code properly make sure |> that if fd 0, 1, and/or 2 were closed before creating the child process, |> that the new fds created for communication with the child do not interfere |> with the three automatic stdio streams? | | I think that the open() calls are protected by dup2() and close(), but indeed | there is a problem with the file descriptors created by the pipe() call. Fixed | as shown below. Thanks for that patch. I still need to play with the idea of swapping over to execute() rather than system(), but it seems like it may be the way to go. In particular, it could even allow a configure-time option for mingw to pick a POSIX shell (particularly when targetting an MSYS build, where such a shell is known to exist), rather than being hard-coded to the current 'cmd /c' provided by system(). But it might also introduce difficulties - the current mingw build is portable to different machines with different directory layouts, but encoding the location of the desired syscmd shell may make the binary locked into a specific installation location for syscmd to work. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhD6AcACgkQ84KuGfSFAYDt0ACffa5h2ODoYAxc4hOShhM+UbiN BT4AnRNRxvw7CCDibHiouCU8TIwuKZsf =NWAF -----END PGP SIGNATURE-----
