[GRASS-dev] Some native Windows changes committed
Paul Kelly
paul-grass at stjohnspoint.co.uk
Wed Dec 20 09:07:03 EST 2006
Just re-visiting some of these issues:
On Fri, 3 Nov 2006, Glynn Clements wrote:
> Paul Kelly wrote:
>
>> Started to abandon the use of G_system() because it hardcodes the use of
>> /bin/sh.
>
> G_system() specifically uses command.com on Windows:
>
> #ifdef __MINGW32__
> signal (SIGINT, SIG_DFL);
> _spawnl ( P_WAIT,
> "command",
> "command",
> "/c",
> command,
> NULL );
> #else
>
> If anything, we should move towards G_system() rather than away from
> it. That would allow various portability hacks to be localised in one
> place rather than spread across modules.
OK that actually didn't work. I changed two things:
- Use cmd.exe (Windows command shell) instead of command.com (old DOS
shell, the last time I looked in detail seemed to be permanently frozen in
a similar state to whatever the current version of DOS was when Windows NT
was first released)
- Use _spawnlp instead of _spawnl. _spawnl requires the full path to the
command being executed (cmd.exe) but this wasn't being given. _spawnlp
looks in the PATH.
After those two changes, G_system() actually seems to work on Windows so
I'll commit them in a while if nobody objects.
>> In many places in modules we have to change calls to G_getl() to G_getl2()
>> to enable them to handle Windows newline sequences - I wonder why G_getl()
>> was not just changed in CVS and then it would fix everything? Changing
>> G_gets() like this to catch everything seems to me like definitely the
>> easiest solution.
>
> Probably because someone thought that there *might* be a situation
> where the CR needed to be preserved, and didn't want to scan the
> entire source tree to check.
Yes, although I keep coming across more situations. I'm almost tempted to
replace the functionality G_getl() with a call to G_getl2(); I keep
finding it causing bugs in obscure places where text files get written
with DOS/Windows line endings and then can't be read. Feel it might be
better to just globally replace all occurences and deal with any bugs
resulting from that rather than changing over on a case-by-case basis.
More information about the grass-dev
mailing list