Thanks very much, Duane, that's just what's needed and does the job in this
case. (without the bracketing mail-injected stars, as you noted.)
Jim Eshelman
www.nepm.net
Network Monitoring with a difference
----- Original Message -----
From: "Duane Bronson" <bronson-nLfnTIhOdZRl57MIdRCFDg@xxxxxxxxxxxxxxxx>
To: "James Eshelman" <james-kId9O9RRFM1BDgjK7y7TUQ@xxxxxxxxxxxxxxxx>
Cc: "L-boston-pm" <boston-pm-PqP1ghmmPMdAfugRpC6u6w@xxxxxxxxxxxxxxxx>; "Tom
Metro" <pm-5a1Jt6qxUNc@xxxxxxxxxxxxxxxx>
Sent: 05/09/2005 10:21 AM
Subject: Re: [Boston.pm] Bizare HTTP::Daemon <=> IE problem on Windows
Some windows processes (GUIs) when run from cmd will return control and
others (command lines) will not. It might have something to do with
closing the stdin/stdout, but I'm not sure. The bottom line is that you
can sometimes get things to launch in the background with "start".
`*start *startupfile.html` and print "problem with startupfile.html due to:
$!\n"; #
Good luck getting that to work on non-windows. Perhaps there's a way to
get Windows perl to obey setting SHELL to "cmd /c start" or something.
James Eshelman wrote:
>No, opening another browser window, or one on another machine, is not
>successful either as long as the first one is still open. I ran
>HTTP::Daemon in the debugger and it became immediately obvious that the
>problem is opening the first IE window in the backticks: When cmd.exe runs
>the first instance of IE, i.e. the first window to open, IE never "returns"
>or completes the process of opening the window, so the web server code
>blocks at that point and never drops into the connect loop, until that
first
>window is closed. By contrast, if another IE instance is already open,
>opening all later ones does get a "return", so no blocking and everything
>runs fine. So it's really not an HTTP::Daemon issue at all, but strictly a
>Windows/cmd.exe/IE question. It's possible that any browser would do this.
>I haven't tested Firefox yet.
>
>Why things have to work this way I'm not sure. Perhaps some Windows/IE
>guru on this list can elucidate this behavior for us.
>
>
>Jim Eshelman
>www.nepm.net
>Network Monitoring with a difference
>
>
|
