perl5
perl5 copied to clipboard
Perl
Ipc open3 localized filehandles
Rather than using STDIN and STDOUT, open our own private file handles that refer to POSIX file descriptors 0 and 1.
This makes open3 work even if STDIN/STDOUT don't refer to file descriptors 0/1 (such as if one of them has been opened for in-memory I/O, for example.)
This replaces https://github.com/Perl/perl5/pull/19575 which should be closed.
On Sat, 02 Apr 2022 04:47:12 -0700 Leon Timmermans @.***> wrote:
That is a unix assumption.
File::Spec->devnullis the portable alternative.
All right, thanks.
I've pushed a commit that fixes this, as well as a couple more commits that fix the STDIN and STDOUT Perl filehandles in the case where we don't exec (ie, where the program is '-').
Regards,
Dianne.
Any thoughts on this? I'd like to see it fixed in Perl rather than maintaining a fork of IPC-Open3.
Lets see what CI says, I just approved them to execute for you. Also we should wait on @Leont to follow up as he already looked at this, he hasn't been around that much the last few days. I don't know this code that well, so I can't say if there are traps and zaps in your proposal, but it looks reasonable given what I do know.
Unfortunately, two tests failed in the "Sanity" phase, but they have nothing to do with IPC-Open3, so not sure where to go from here.
Please run Porting/updateAUTHORS.pl and review and commit the result and push it as part of this patch.
I'm not confident about changing the behavior of this module this late in our release schedule, I would propose postponing that until 5.37
OK, thanks; I pushed updates to AUTHORS and bumped the version.
I'm fine with postponing the release of this module, but I would like to see it released eventually.
Regards,
Dianne.
Given you are good with waiting, perhaps you could rebase -i and squash down the fixup commits and then force push a nice clean commit sequence? Then it would be ready for merge early in the 5.37 branch for testing to see if it causes any trouble. Since nobody has requested any changes since @leont did 10 days ago I think now would be a good time to clean up the PR for release.
This breaks on Windows. :( I have no access to a Windows system, so wouldn't know how to fix it. I can make the tests conditional on the OS being UNIX, but are we willing to have IPC-Open3 behave differently on UNIX vs Windows?
I think maybe @xenu might be able to help you? I believe he works on Windows.
Note the mingw64 often fails a test (cant remember which one off the top of my head, socket maybe?) so when that is the only test fail you see then you can ignore it.
BTW, if you rebase and force push then at least one of the test fails, the i386 fail, should fix itself.
The Windows tests hang. Unfortunately, as I don't have access to a Windows machine, I'm not really sure what to do about this... either don't run the failing tests on Windows, or have someone with access to Windows look into making it work on that platform.
