Re: TAP test breakage on MacOS X

On Thu, Oct 30, 2014 at 04:54:25PM +0100, Andres Freund wrote:
> On 2014-10-30 01:57:15 -0400, Noah Misch wrote:
> > On Wed, Oct 29, 2014 at 08:14:07PM -0400, Peter Eisentraut wrote:
> > > On 10/28/14 9:09 PM, Peter Eisentraut wrote:
> > > > I have looked into IPC::Cmd, but the documentation keeps telling me that
> > > > to do anything interesting I have to have IPC::Run anyway. I'll give it
> > > > a try, though.
> > >
> > > I tried this, but I'm not optimistic about it. While parts of IPC::Cmd
> > > are actually a bit nicer than IPC::Run, other parts are weird. For
> > > example, with most packages and functions in Perl that run a command,
> > > you can pass the command as a string or as a list (or array reference).
> > > The latter is preferred because it avoids issues with quoting, word
> > > splitting, spaces, etc. In IPC::Run, I can use the "run" function in
> > > the latter way, but I cannot use the "run_forked" function like that,
> > > and I need that one to get the exit code of a command. It's possible to
> > > work around that, but I'm getting the feeling that this is not very well
> > > designed.
> >
> > 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.
> >
> > Any others worth noting?
>
> 5. Include a copy of IPC::Run in the repository till it's common enough.

True. I eliminated that one because the license of IPC::Run is, like Perl
itself, GPL+Artistic. Right now, we presume that the entire PostgreSQL
tarball is distributable under the PostgreSQL License. The benefit of
bundling IPC::Run is not strong enough to justify muddying that.