On Thu, Oct 30, 2014 at 01:57:15AM -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.
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
