On 2022-11-17 Th 01:18, Noah Misch wrote: > On Mon, Aug 22, 2022 at 09:44:42AM -0400, Andrew Dunstan wrote: >> On 2022-08-21 Su 20:40, Noah Misch wrote: >>> This (commit 13d856e of 2015-07-29) added the following: >>> >>> --- a/src/test/perl/TestLib.pm >>> +++ b/src/test/perl/TestLib.pm >>> @@ -242,7 +288,17 @@ sub command_exit_is >>> print("# Running: " . join(" ", @{$cmd}) ."\n"); >>> my $h = start $cmd; >>> $h->finish(); >>> - is($h->result(0), $expected, $test_name); >>> + >>> + # On Windows, the exit status of the process is returned directly as the >>> + # process's exit code, while on Unix, it's returned in the high bits >>> + # of the exit code (see WEXITSTATUS macro in the standard <sys/wait.h> >>> + # header file). IPC::Run's result function always returns exit code >> >>> 8, >>> + # assuming the Unix convention, which will always return 0 on Windows as >>> + # long as the process was not terminated by an exception. To work around >>> + # that, use $h->full_result on Windows instead. >>> + my $result = ($Config{osname} eq "MSWin32") ? >>> + ($h->full_results)[0] : $h->result(0); >>> + is($result, $expected, $test_name); >>> } >>> >>> That behavior came up again in the context of a newer IPC::Run test case. >>> I'm >>> considering changing the IPC::Run behavior such that the above would have >>> been >>> unnecessary. However, if I do, the above code would want to adapt to handle >>> pre-change and post-change IPC::Run versions. If you have an opinion on >>> whether or how IPC::Run should change, I welcome comments on >>> https://github.com/toddr/IPC-Run/issues/161. >> Assuming it changes, we'll have to have a version test here. I don't >> think we can have a flag day where we suddenly require IPC::Run's >> bleeding edge on Windows. So changing it is a good thing, but it won't >> help us much. > IPC::Run git now has the change, and we may release soon. Here's what I plan > to push to make PostgreSQL cope.
LGTM cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com