Re: system(), Solaris, and the 'execute' module

[Eric Blake]

-----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             address@hidden
-----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-----