Re: Peter Eisentraut 2014-11-03 <5457F54E.4020805@gmx.net>
> On 11/2/14 2:00 PM, Noah Misch wrote:
> >> Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
> >> Thanks for investigating. So, surviving options include:
> >>
> >> 1. Require IPC::Run.
> >> 2. Write our own run() that reports the raw exit code.
> >> 3. Distill the raw exit code from the IPC::Cmd::run() error string.
> >> 4. Pass IPC::Run::run_forked() a subroutine that execs an argument list.
> >
> > FWIW, (3) looks most promising to me. That is to say, implement a reverse of
> > IPC::Cmd::_pp_child_error(). Ugly to be sure, but the wart can be small and
> > self-contained.
>
> I thank you for this research, but I suggest that we ship 9.4 as is,
> that is with requiring IPC::Run and --enable-* option. All the possible
> alternatives will clearly need more rounds of portability testing. We
> can then evaluate these changes for 9.5 in peace.
Hrm. I spent some effort into getting the TAP tests to run on 9.4beta
for Debian, and I've only now learned that 9.4.0 doesn't run them
unless I say --enable-tap-tests. A short note to -packagers would have
been nice, for a change so late in the release cycle...
Christoph
--
cb@df7cb.de | http://www.df7cb.de/
