Re: fork_to_background() on Windows
Gisle Vanem wrote: I've searched google and the only way AFAICS to get redirection in a GUI app to work is to create 3 pipes. Then use a thread (or run_with_timeout with infinite timeout) to read/write the console handles to put/get data into/from the parent's I/O handles. I don't fully understand how yet, but it could get messy. Just for the sake of running Wget in the background, it doesn't seem to be worth. Unless someone else have a better idea. I agree. One can always open new command windows for wget or another application to run in. Tony
Re: fork_to_background() on Windows
The shell is smart enough to run those 2 commands in series. If wget is a GUI app, it runs them in parallell causing gzip to fail. wget -O- http://host/index.html | most works kind of; only some of the stdout data gets displayed. I've searched google and the only way AFAICS to get redirection in a GUI app to work is to create 3 pipes. Then use a thread (or run_with_timeout with infinite timeout) to read/write the console handles to put/get data into/from the parent's I/O handles. I don't fully understand how yet, but it could get messy. Just for the sake of running Wget in the background, it doesn't seem to be worth. Unless someone else have a better idea. --gv
Re: fork_to_background() on Windows
Gisle Vanem [EMAIL PROTECTED] writes: It could be a useful feature if we attach to the console of calling process (the shell in most cases) at startup. Then when ^Break is pressed (or '-b' specified), we free that console and continue running in the background. That way we will get the shell prompt back (and not as it is know with Wget seemingly hanging idle until finished). Making `-b' work would be great. But is it really desirable for ctrl-break to put Wget in background? I thought ctrl-break was supposed to interrupt and abort the program, like ^C on Unix? Hmm, now I see that ctrl-break backgrounds Wget even now, so I guess people don't mind; I don't remember receiving a report for this. * In mswindows.c, add a WinMain() function that sets up a detached console (or for Win-9x/ME/NT allocates one). Reopen stdin, stdout and stderr using $CONIN etc. Call wget_main(). BTW. We could do the Winsock init stuf here too to avoid cluttering main.c Agreed. This actually works fine, but redirection (e.g. wget -h foo) doesn't work.I don't know any way to get at the redirected stdout/stderr handles from Wget. But then you're not supposed to do that from a GUI app. Most people won't think of Wget as a GUI application, but it might be OK for redirecting `-h' not to work because very few people use redirections on Windows (as far as I know). But does something like `wget -O - FILE' work now? How about `wget -O - | command...'? If those currently work, we might want to be careful not to break them. Anybody see other ways to run detached or in background. I haven't checked how Cygwin's fork() does it, but hear it is pretty slow. Cygwin's fork() is probably fast enough for what Wget needs to do with it. But, from what I read of it, it's heavy magic which is not easy to extract out of Cygwin.
Re: fork_to_background() on Windows
Hrvoje Niksic [EMAIL PROTECTED] said: Making `-b' work would be great. But is it really desirable for ctrl-break to put Wget in background? I thought ctrl-break was supposed to interrupt and abort the program, like ^C on Unix? Hmm, now I see that ctrl-break backgrounds Wget even now, so I guess people don't mind; I don't remember receiving a report for this. ws_handler() now acts on ^C and ^Break depending on #define. Maybe Windows could be told to use ^Z as interrupt key?. redirections on Windows (as far as I know). But does something like `wget -O - FILE' work now? How about `wget -O - | command...'? If those currently work, we might want to be careful not to break them. Using - and redirection works if linking as a console app (the default). And wget -O- http://host/index.html | most works fine, but not as a GUI app. Since a GUI app (or a subsystem 2 specified in the PE-header), doesn't get a console when it's started. If I in my shell (4NT or CMD) do: wget http://host/file.tar.gz gzip -d file.tar.gz The shell is smart enough to run those 2 commands in series. If wget is a GUI app, it runs them in parallell causing gzip to fail. wget -O- http://host/index.html | most works kind of; only some of the stdout data gets displayed. --gv
