in reply to Re^4: Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE (sources)
in thread Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE

The flags are on the OsFHandle and yet you are trying to share the Unixish 'fd'. Try $ENV{myosh} = $os_handle; instead and then open an fd and fh for that in the spawned process (via OsFHandleOpen).

That's how I've done this successfully before.

- tye        

  • Comment on Re^5: Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE (wrong layer)
  • Download Code

Replies are listed 'Best First'.
Re^6: Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE (wrong layer)
by Yary (Pilgrim) on Dec 05, 2012 at 16:14 UTC
    That works. Adding $ENV{myosh} = $os_handle; to the caller (also removing SetHandleInformation, it isn't needed) and rewriting print_to_3.pl as 
    use Win32API::File qw(OsFHandleOpen);

OsFHandleOpen(\*OUT,$ENV{myosh},"w");
$x=print OUT "***\nHere is data to OsH $ENV{myosh}\n***\n";
warn "print=$x ($!)\n" unless $x;

    [download]
    works... Alas the "real" code I am dealing with that "print_to_3.pl" replaces is Unix-y C code. I have already made it use STDERR instead of its own stream, which is working well enough- if there's an error message then the stream is no good anyway, and in the usual case it's easier to manipulate STDERR .
[reply]
[d/l]

In Section Seekers of Perl Wisdom