From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Jul 29 12:30:41 2003 Subject: Win 98 support patch From: "John W. Eaton" To: Paul Kienzle cc: octave-maintainers mailing list Date: Tue, 29 Jul 2003 12:30:32 -0500 On 25-Jul-2003, Paul Kienzle wrote: | The attached patch removes some major inconveniences when running | under Windows 9x. Simple commands like ls or help would freeze | the computer for 7 sec then give a series of dire warnings about | each loaded oct-file. | | As far as I can tell, the patch doesn't remove any useful | functionality. What about not being able to get the actual PID of the subprocess? Perhaps we never use that anywhere? | The correct status is still returned function calls. Interrupts still | break the piped application rather than killing octave. Killing the | pager still leaves the keyboard echo turned off in the console, only to | be fixed by system('reset'). Octave still responds appropriately if it | detects that gnuplot has been killed (which BTW it may not since pgnuplot | doesn't die when the gnuplot console is closed). This is despite the | fact that SIGCHLD isn't being handled correctly (SIGCHLD should use | default signal handling rather than doing it's own waits if popen is | in effect according to the docs --- this may not be the case for | octave_iprocstream under unix), and despite that fact that the | buffered child cleanup function is not being called (though I didn't | look in detail at what child cleanup is needed for pager/gnuplot). OK. I'm not sure what is correct for handling SIGCHLD. | I haven't removed the fork in system('cmd','async'). In practice, | users can say system('cmd &') instead, so it isn't too much of an | issue. But can they still get the PID of the subprocess? OTOH, I think that you actually get the PID of the shell process anyway, so I'm not sure how useful that is. In any case, I've installed your changes. jwe