Sorry, see what I just forwarded to the list - in fact, for most things the console *doesn't* seem to be needed. It's just the application that I'm using, Spidey, that seems to be causing problems. It's very wierd ...
> I believe that this problem is normal for Windows. If the application is > a GUI only app > it is run detached from any console, and does not have any STDIN or > STDOUT handles > open, either to receive pipes as a child or to be inherited by a child > (i.e. a backtick > command). You can see the same thing with wperl.exe which is only > perl.exe with the > same change made as a pp app with --gui: > > C:\test>type tt.pl > my $t = <>; print "$t\ndone\n"; > > C:\test>type tt.pl | perl tt.pl > my $t = <>; print "$t\ndone\n"; > > done > > C:\test>type tt.pl | wperl tt.pl > > C:\test> > > > wperl.exe cannot receive the piped copy of tt.pl on STDIN or print > anything to STDOUT. > I haven't tested this myself but there is a good discussion about hiding > console > windows at: > > http://www.winnetmag.com/WindowsScripting/Article/ArticleID/16299/16299.html > > I presume that a hidden but still existing console still has an open > STDIN/STDOUT for > pipes. > > Alan Stewart > -- http://www.fastmail.fm - IMAP accessible web-mail
