[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

wait-process API limitation

From: Eric Blake
Subject: wait-process API limitation
Date: Mon, 20 Jul 2009 05:29:31 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090605 Thunderbird/ Mnenhy/

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
$ echo 'esyscmd(echo `dnl'\''; exit 127)sysval' | m4-1.4.13
m4-1.4.13: esyscmd subprocess failed

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]