New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPC::Open3 directs output incorrectly when STDOUT not connected to fd#1 #9759
Comments
From @scottgiffordThis is a bug report for perl from sgifford@suspectclass.com, IPC::Open3::open3 directs output incorrectly if STDOUT is set to a Here is a script that demonstrates the problem: ===8<===8<===8<===8<=== use warnings; use IPC::Open3; # Basic setup stuff # Now set STDOUT to a filehandle on a new descriptor # Run the command # And copy the output exit(0); The expected output from this is: PIPE: out 1 which indicates that the child process had both standard output and Instead, with both IPC::Open3 1.02 and 1.03, I get this output: out 1 This indicates that the standard output from the script didn't go If you look around line 246 of Open3.pm, you'll see this code: if ($dup_rdr) { That will ensure that Perl's STDOUT filehandle is connected to the This patch to IPC/Open3.pm seems to fix the problem: ===8<===8<===8<===8<=== Inline Patch--- /usr/share/perl/5.8.8/IPC/Open3.pm 2009-01-14 17:58:13.000000000 -0500
+++ fixed/IPC/Open3.pm 2009-06-03 01:10:14.000000000 -0400
@@ -3,6 +3,7 @@
use strict;
no strict 'refs'; # because users pass me bareword filehandles
our ($VERSION, @ISA, @EXPORT);
+use POSIX;
require Exporter;
@@ -134,30 +135,33 @@
}
if ($dup_wtr) {
- xopen \*STDIN, "<&$dad_wtr" if fileno(STDIN) != xfileno($dad_wtr);
+ POSIX::dup2(xfileno($dad_wtr), 0) if 0 != xfileno($dad_wtr);
} else {
xclose $dad_wtr;
- xopen \*STDIN, "<&=" . fileno $kid_rdr;
+ POSIX::dup2(fileno($kid_rdr), 0);
}
+
if ($dup_rdr) {
- xopen \*STDOUT, ">&$dad_rdr" if fileno(STDOUT) != xfileno($dad_rdr);
+ POSIX::dup2(xfileno($dad_rdr), 1) if 1 != xfileno($dad_rdr);
} else {
xclose $dad_rdr;
- xopen \*STDOUT, ">&=" . fileno $kid_wtr;
+ POSIX::dup2(fileno($kid_wtr), 1);
}
if ($dad_rdr ne $dad_err) {
if ($dup_err) {
# I have to use a fileno here because in this one case
# I'm doing a dup but the filehandle might be a reference
# (from the special case above).
- xopen \*STDERR, ">&" . xfileno($dad_err)
- if fileno(STDERR) != xfileno($dad_err);
+ POSIX::dup2(xfileno($dad_err), 2)
+ if 2 != xfileno($dad_err);
} else {
xclose $dad_err;
- xopen \*STDERR, ">&=" . fileno $kid_err;
+ POSIX::dup2(fileno($kid_err), 2);
}
} else {
- xopen \*STDERR, ">&STDOUT" if fileno(STDERR) != fileno(STDOUT);
+ if (fileno(STDERR) != fileno(STDOUT)) {
+ POSIX::dup2(1, 2);
+ }
}
if ($cmd[0] eq '-') {
croak "Arguments don't make sense when the command is '-'"
Since POSIX::dup2 works explicitly with file descriptors, this will With this patch, the above test program works properly for me. Flags: Site configuration information for perl v5.8.8: Configured by Debian Project at Wed Jan 14 22:46:08 UTC 2009. Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Locally applied patches: @INC for perl v5.8.8: Environment for perl v5.8.8: |
@scottgifford - Status changed from 'new' to 'open' |
From @ikegamiHas this been tested on Windows? fd 0,1,2 as stdin/out/err and dup2 are And there's the nit that xopen performs error checking but your |
From @scottgiffordOn Fri Jun 05 10:11:48 2009, ikegami@adaelis.com wrote:
No. If the general thrust of my solution seems right, I'll try it out on
Yeah, good point, if everything else looks OK I can fix that. -----Scott. |
From [Unknown Contact. See original ticket]On Fri Jun 05 10:11:48 2009, ikegami@adaelis.com wrote:
No. If the general thrust of my solution seems right, I'll try it out on
Yeah, good point, if everything else looks OK I can fix that. -----Scott. |
From @CorionHello, I can confirm the problem for bleadperl on Windows. Unfortunately, if I Please find attached the modified test file, which should work across -max PS: On a purely stylistic note, please do use POSIX () to avoid importing all the symbols that POSIX.pm exports, especially |
From @Corion |
From roger.j.meier@gmx.chHad the same problem when using open3() to start a process from a The attached Open3.pm patch worked for me: It uses dup2() implicitly by open(STDOUT, ">&=1"); Since it's used only within the forked process, resetting the original |
From ambs@zbr.ptHaving this same problem on Mac OS X, perl 5.12.2, IPC::Open3 v1.05, As this ticked was opened about 1 year ago, I wonder what other Cheers |
From ambs@zbr.ptOn Sat Dec 18 10:53:01 2010, ambs wrote:
Patch by rogerjmeier (adding the two open >&=1 and >&=2) seems not to |
From ambs@zbr.ptProbably this doesn't help much, but in attach a summarized version of |
From ambs@zbr.ptOpen3 Starts: 22220 close(4) = 0 Here, FD 13 is STDERR Meanwhile, the process (cqp) loads a set of libraries, and accesses a set of local files. And it continues: 22220 rt_sigaction(SIGPIPE, {SIG_IGN, [PIPE], SA_RESTORER|SA_RESTART, 0x3699632a20}, {SIG_IGN, [], 0}, 8) = 0 That is, cqp wrote to stdout (1) 22220 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B9600 opost isig icanon echo ...}) = 0 And starts reading on 0... and ends when I kill the cqp process 22220 <... read resumed> 0x7fad3d116000, 1024) = ? ERESTARTSYS (To be restarted) |
From ambs@zbr.ptApplying the patch from sgifford (first from the thread) things work. |
From ambs@zbr.ptAdded a diff to add a test to this into HEAD@git. I'm happy to help solving this bug, accordingly with my own limitations. |
From ambs@zbr.pt |
From ambs@zbr.ptOn Sun Dec 19 12:54:59 2010, ambs wrote:
Tested the two line patch above: and the added test works. But there is some issue with STDIN as well. The other solution (POSIX based) solves that STDIN problem as well. |
From @jkeenanOn Sun Dec 19 13:53:42 2010, ambs wrote:
Are there still issues to be resolved in this ticket? (I looked for the code which the OP cited in Thank you very much. |
From @scottgiffordThe code at: doesn't look much different than the code I reported in the original bug, and nobody has ------Scott. |
From @jkeenanOn Fri Feb 15 20:29:11 2013, sgifford wrote:
Scott, the link you cite displays version 1.05 of IPC-Open3. However, Would it be possible for you to re-test with either 1.12 or 1.13? Thank you very much. |
From @arcJames E Keenan via RT <perlbug-followup@perl.org> wrote:
I've run Scott's original test script on newer Perl and IPC::Open3, -- |
Migrated from rt.perl.org#66224 (status was 'open')
Searchable as RT66224$
The text was updated successfully, but these errors were encountered: