-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [adding m4-discuss]
According to Bruno Haible on 5/27/2008 4:43 PM: | Hi Eric, | | It seems that your problem is that you want execute a script via system() | and at the same time force a particular shell, namely the $CONFIG_SHELL found | at configure time? Something along those lines - POSIX doesn't require m4 to use system(2), merely that it treat the argument to the syscmd macro as a shell command. ~ But if you want a POSIX-compliant m4 on Solaris, then syscmd must not use /bin/sh, since /bin/sh doesn't obey the POSIX rules of parsing shell commands. Using $CONFIG_SHELL from configure-time is likely to be a POSIX shell, but your luck is even better if we used the equivalent of finding sh in 'command -p getconf _CS_PATH'. | |> $ gcc -o foo -Wall foo.c /usr/ccs/lib/values-xpg4.o | | I would not use this approach for three reasons: | | 1) When you have to use /usr/ccs/lib/values-xpg4.o to get a particular | behaviour, the chances are high that you will not be able to find a | solutions for some other systems. As far as I can see, the problem is limited to Solaris, which is specifically documented as having two different system(2) implementations, based on what the compile-time environment requested. | 2) Linking with /usr/ccs/lib/values-xpg4.o may be contradictory with | the CC options. If you set CC and CFLAGS so as to get traditional | behaviour and then link with a file to get XPG4 behaviour, I would | not bet that there aren't bad side-effects. True. I guess if a user is concerned about POSIX compliance on Solaris, then they have control over the compiler and flags to ensure that. It's a bit of a shame that they can't get POSIX compliance without using non-default flags, though. Documentation in INSTALL might be valuable here. | |> Should we figure out a way to make inclusion of the extensions module cause |> compilation on Solaris to favor the standards-compliant behavior of various |> functions? Should we try to directly add values-xpg4.o to the link line, or |> are we better off providing a .c file which provides the same definition of |> __xpg4 as what values-xpg4.o provides? | | 3) You are assuming a program being built. But gnulib is also used to build | libraries, such as libgettextpo or Simon's crypto libraries. What effect | would it have to put values-xpg4.o into such a shared library? It would | probably cause a change of behaviour to _all_ programs linked with such a | library. Good points. But all it can do is make the program more likely to be POSIX compliant. In other words, I'm not yet convinced that always using xpg4 semantics is bad. | | Instead I would stop using the 'system' function (in particular its signal | handling behaviour is more often undesired than desired) and use the 'execute' | module instead. It allows you to specify the program to be launched explicitly, | without any hacks. 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, which would be a loss in functionality (and a difference from Solaris m4 behavior). Also, m4 currently uses both system (for syscmd) and popen (for esyscmd); it looks like the pipe module (specifically create_pipe_in) is the counterpart for esyscmd (although it uses fd rather than FILE *, so it would need some wrapping with fdopen before being used in m4). Finally, 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? - -- 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 iEYEARECAAYFAkg80pYACgkQ84KuGfSFAYDLEwCgoq/svD6dPjYkX/N4cc9/gBxp WaQAoKJdZOUdnQNnhst5rbPLtoVB7gBn =GlUb -----END PGP SIGNATURE-----
