From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TAP test breakage on MacOS X |
Date: | 2014-10-30 05:57:15 |
Message-ID: | 20141030055715.GA406517@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> Also, IPC::Cmd is a wrapper module, and it passes the hard work down to
> other modules, depending on what's available. I think that sounds like
> a portability problem waiting to happen.
Assuming test suite code doesn't modify $IPC::Cmd::USE_* variables, the two
relevant backends are IPC::Run on Windows and IPC::Open3 everywhere else.
That's not bad.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-10-30 08:04:37 | Re: printing table in asciidoc with psql |
Previous Message | Amit Kapila | 2014-10-30 04:53:56 | Re: Lockless StrategyGetBuffer() clock sweep |