-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Right now, wait_subprocess assumes that an exit status of 127 from the child process implies failure, and prints a message unless null_stderr is set. However, this led to a regression in m4 1.4.13 - an intentional status of 127 is ambiguous with failure only if the child had no output, and although m4 knows there was output, wait-process does not:
$ echo 'esyscmd(echo `dnl'\''; exit 127)sysval' | m4-1.4.11 127 $ echo 'esyscmd(echo `dnl'\''; exit 127)sysval' | m4-1.4.13 m4-1.4.13: esyscmd subprocess failed 127 The fix from m4's point of view is to pass null_stderr=false to create_pipe_in, but null_stderr=true to wait_subprocess, but this feels like a bit of a hack, because of the inconsistency in the named parameter. Maybe it would be worth an API change to wait_subprocess to add an additional bool parameter, status_127_ok, which silences this particular error message if the calling process knows for certain that the child process produced output (or even if the parent process does not know this, but will be handling status 127 itself without additional output from the gnulib module). Or, maybe it is worth just renaming the existing parameter to more accurately reflect its purpose within wait_subprocess, making it obvious that passing a different value than what was passed to create_pipe_*'s null_stderr is acceptable. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----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 iEYEARECAAYFAkpkVRsACgkQ84KuGfSFAYCLugCdHFDOoWwf7OSWPuTnzxrI8kI6 NjUAoJ3w2w+X94bPYNb2eBukBIVWZCMs =BvUu -----END PGP SIGNATURE-----
