Skip to content
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

Issue with IPC::Open3 on Windows #14533

Open
p5pRT opened this issue Feb 23, 2015 · 5 comments
Open

Issue with IPC::Open3 on Windows #14533

p5pRT opened this issue Feb 23, 2015 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Feb 23, 2015

Migrated from rt.perl.org#123904 (status was 'open')

Searchable as RT123904$

@p5pRT
Copy link
Author

p5pRT commented Feb 23, 2015

From skneizys@yahoo.com

Many years ago it was first reported that IPC​::Open2/3 emulation on Windows had a major drawback​:  The closing of a parent's "write to child" file handle did not result in the child getting that message.  
People have tried totally CRAZY things to try to work around it, for example​:http​://stackoverflow.com/questions/12011300/perls-waitpid-and-ipcopen2-in-windows-vs-linux-unix

I found this pearl, er, perl of wisdom from the monks​:http​://www.perlmonks.org/bare/index.pl?node_id=1109928

Windows and pipes that don't close

|   |
|   |   |   |   |   |
| Windows and pipes that don't closeI am working on a new backend for my Net​::SSH​::Any module which uses an external SSH client (ssh or plink) to connect to the remote host. |
| |
| View on www.perlmonks.org | Preview by Yahoo |
| |
|   |

I thought it would be great to actually get that into IPC​::Open3 itself, so I did​:
--- /tmp/.diff1115838923 2015-02-22 21​:25​:02.210845933 -0400+++ /tmp/.diff1443510633 2015-02-22 21​:25​:02.210845933 -0400@​@​ -229,6 +229,16 @​@​  next if $_->{dup} or $_->{dup_of_out};  if ($_->{mode} eq '<') {     xpipe $_->{open_as}, $_-&gt;{parent};+            # SPK fix issue with parent closing child's STDIN but child not+            # getting that message on Windows the way it happens on *nix+            if ($^O eq 'MSWin32') {+                my $code="use Win32API​::File qw(​:Func :HANDLE_FLAG_);";+                $code.='my $wh = FdGetOsFHandle(fileno $_->{parent});';+                $code.='SetHandleInformation($wh, HANDLE_FLAG_INHERIT, 0);';+                eval($code);+                croak "Can't turn off HANDLE_FLAG_INHERIT​: $@​" if $@​;+            }+            #end SPK fix  } else {     xpipe $_->{parent}, $_->{open_as};  }
And VOILA!  I have been able to use RT's email function on Windows.  I'm not sure what the best way to do that conditional OS module load, maybe there is a more efficient way other than eval.
Thanks,
Steve...

@p5pRT
Copy link
Author

p5pRT commented Feb 23, 2015

From skneizys@yahoo.com

--- /tmp/.diff1115838923 2015-02-22 21​:25​:02.210845933 -0400
+++ /tmp/.diff1443510633 2015-02-22 21​:25​:02.210845933 -0400
@​@​ -229,6 +229,16 @​@​
  next if $_->{dup} or $_->{dup_of_out};
  if ($_->{mode} eq '<') {
  xpipe $_->{open_as}, $_->{parent};
+ # SPK fix issue with parent closing child's STDIN but child not
+ # getting that message on Windows the way it happens on *nix
+ if ($^O eq 'MSWin32') {
+ my $code="use Win32API​::File qw(​:Func :HANDLE_FLAG_);";
+ $code.='my $wh = FdGetOsFHandle(fileno $_->{parent});';
+ $code.='SetHandleInformation($wh, HANDLE_FLAG_INHERIT, 0);';
+ eval($code);
+ croak "Can't turn off HANDLE_FLAG_INHERIT​: $@​" if $@​;
+ }
+ #end SPK fix
  } else {
  xpipe $_->{parent}, $_->{open_as};
  }

@p5pRT
Copy link
Author

p5pRT commented Feb 23, 2015

From skneizys@ferrilli.com

I am actually wondering if the fix doesn't actually belong deeper in the
code at the time of the creation of the pipe. Maybe it does not belong in
a perl module, if all pipes on Windows are affected it should be in the
base code.

@p5pRT
Copy link
Author

p5pRT commented Feb 23, 2015

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Feb 24, 2015

From skneizys@ferrilli.com

I am actually wondering if the fix doesn't actually belong deeper in the
code at the time of the creation of the pipe. Maybe it does not belong in
a perl module, if all pipes on Windows are affected it should be in the
base code.

@xenu xenu removed the Severity Low label Dec 29, 2021
briandfoy added a commit to briandfoy/PerlPowerTools that referenced this issue Jun 18, 2023
briandfoy added a commit to briandfoy/PerlPowerTools that referenced this issue Jun 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants