AnyEvent::Util::run_cmd on Windows

Tanktalus has asked for the wisdom of the Perl Monks concerning the following question:

I must be using this wrong on Windows. The code works on Unix, but seems to hang on Windows. A secondary problem is that the filehandles seem to get messed up, which I'm guessing is due to the way forking is emulated on Windows. Here's a snippet (strict/warnings/etc implied).

my $cv = AnyEvent::Util::run_cmd(
  [ $^X, -e => 'print "hello $^V\n"; exit 3' ],
  '>'  => '/my.out', # for simplicity - somewhere that I have write ac
+cess is being used
  '2>' => '/my.err',
);
print "Started.\n"; # this goes to /my.out on windows, to the terminal
+ on unix
my $rc = $cv->recv; # this hangs on windows, returns nearly instantly 
+on unix
[download]

I've tried with both 32-bit perl 5.10.0 (ActiveState) and 64-bit 5.22.1 (unknown source), and got the same results. (Windows 2008, but I doubt that matters.)

I started out with a reduced-functionality version of run_cmd, with an intention to eventually move to AE, but it had some similar problems, and I figured that the AE author may have worked around those problems already, so I started testing with AE instead, got stuck here. If AE doesn't work here, I may be forced to try to find a solution to my reduced-functionality version (which mostly was around the fork/filehandle issue - I'm sure I can resolve that, in a subprocess if I have to), but I'm figuring there has to be a simpler way, preferably one that will eventually allow me to read in both stdout and stderr without the temporary files.

Any suggestions would be appreciated.

Comment on AnyEvent::Util::run_cmd on Windows Download Code

Replies are listed 'Best First'.
Re: AnyEvent::Util::run_cmd on Windows by Discipulus (Canon) on Jun 07, 2017 at 07:33 UTC
Hello Tanktalus, do not expect more than a rubber duck debugging from me.. but maybe you can spot something interesting. First i found a mention of the same issue and the author answers: > It should work fine on windows, but probably places high demands on your fork implementation, so activestate perl might not work (and strawberry perl is probably as broken as always). Try a cygwin/sfu/uwin or so perl and see if it works better there. After this i found that the last succesfull test with 5.24 on windows has the most part of tests skipped and a clear mention that it might works on cygwin.. bad sign Also looking to the source of the run_cmd it uses other functions that are esplicitly deprecated for the win platform as `portable_pipe` I played a little with your code and changed `/my.out` (you mean `./my.out` perhaps?) into `my.out` but it hangs until i kill the program an so i found `Terminating on signal SIGINT(2)` into `my.err` file. When I put `$\|++` at the top of the program and added a `and die` to `my $rc = $cv->recv;` i found the `Started` into the terminal as you noted for Linux platform. Maybe this module is not the best choice for that platform.. I'm not an expert at all but have you considered using MCE that does a big effort to be usable and efficient on win32 platform too? or IPC::Run to get rid of STDOUT STDERR of an external program? L* There are no rules, there are no thumbs.. Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.	[reply] [d/l] [select]
Re^2: AnyEvent::Util::run_cmd on Windows by Anonymous Monk on Oct 06, 2018 at 18:09 UTC
As a sidenote, portable_pipe is of course not deprecated, but recommended for the windows platform (it explicitly says so in both documentation and source), as perl's pipe builtin is broken in most windows perls.	[reply]
Re: AnyEvent::Util::run_cmd on Windows by talexb (Chancellor) on Jun 07, 2017 at 13:32 UTC
Did the tests all pass when this package was installed? That might give you more information to chase this down. Also wondering if you can write the equivalent script using just `fork` to achieve the same thing, in order to confirm that `fork` behaves the way you expect on Windows. Perhaps develop on *nix, then copy over to Windows? I would also try using completely different file handles in the child process, in order to eliminate the file handle issue. Alex / talexb / Toronto Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.	[reply] [d/l] [select]