Win98 support

[Paul Kienzle]

Hi,

I've had some success with Windows 98 support
by replacing fork/exec with popen calls.  The
mouse no longer freezes, and I don't get an
error box popping up for each oct-file that
I have loaded.  I can now view tex-infoed help
through the pager. Finally, this will make 
octave usable on windows 98.

One thing that is lost in the conversion is
the process id, which is used by pager and
gnuplot to clean up after the child exits.  I
haven't looked in detail at the code to see
if there is a better way.  Since each popen
has a corresponding pclose, I imagine its
just a question of putting the cleanup after
the pclose.

There are a few more uses of fork, such as
the one in system().  It seems to be there
so that games can be played with signals.
I don't know what happens yet if we just
call the MSVCRT version of system.  The
one in fork() has to stay I guess.  The
third one is in listen() from octave-forge 
where I'm using it to spawn a child from 
the octave server, but I don't know what
to do about it yet.

To test the signals, I was playing with the
edit_history command.  edit_history uses
TMPDIR from the environment, which octave
initializes from cywin_to_win_path("/tmp"),
which dutifully produces C:\cygwin\tmp on
my machine.  This is used by tempname to
create C:\cygwin\tmp/oct-xxxxxx.  The
problem is that system() uses sh, which
treats the \ as an escape character, so
the file becomes C:cygwintmp/oct-xxxxx,
which does not exist.

I could fix TMPDIR on cygwin initialization,
which will get around the immediate problem.
I don't thing we can do anything automatic
in system().  The user may want to embed
escape sequences in the system command, so
we can't just double them all up or replace
them with / before sending the command to sh.
Suggestions?

BTW, my octave_procbuf changes make
the procstream class even more like the
octave_procstream class.  Any reason
to keep them separate?

Paul Kienzle
address@hidden