[GRASS-dev] Re: testing native winGRASS

[Glynn Clements]

Moritz Lennert wrote:

> >>>> 1) Create location with projection values: location created but mapset
> >>>> (other than PERMANENT) invalid
> >>>
> >>> Could you try the patch below for lib/gis/getl.c and see if GRASS can
> >>> then handle the newly created location? I think the problem is the
> >>> created location contains Windows line endings in some of the files and
> >>> other GRASS functions can't handle them. G_getl2() handles Windows line
> >>> endings whereas G_getl() does not. I have a hunch this may apply in many
> >>> places.
> >>
> >> I will try this tonight, but just to make clear what is going wrong:
> >> creating the location works and there is a valid PERMANENT mapset
> >> created whatever I do, but if (in the console window where you enter the
> >> name of the new location) I give a mapset name other than PERMANENT,
> >> this mapset is then created (together with PERMANENT), but when I try to
> >> enter it, I get an "invalid mapset" error, which is understandable since
> >> the mapset directory is empty except for a dbf directory (IIRC).
> > 
> > Ah OK. I believe the problem is this in lib/init/mke_mapset.c:
> > 
> > /* give the mapset a default window for the entire location */
> >         sprintf(buffer,"cat '%s'/PERMANENT/DEFAULT_WIND  > '%s'/'%s'/WIND",
> >                 location, location, mapset) ;
> >         system(buffer) ;
> 
> Glynn has taught me about the rename() and remove() function, but I
> haven't come upon a copy() function, yet...

There isn't one. There isn't even a universal definition of "copying"
a file (e.g., what happens if the target already exists, does copying
a symlink create a symlink or a copy of the file it points to, etc).

> Probably some combination of fscanf & fwrite...
> Or getc & putc : http://www.java2s.com/Code/C/File/Copyafile.htm
> 
> If it really doesn't exist, shouldn't we implement G_fcopy() or
> something like that. Possibly in lib/gis/copy.c ?

That could be a useful addition. But in the case of copying
PERMANENT/DEFAULT_WIND to <mapset>/WIND file, I'd suggest trying
either G_get_default_window() and G_put_window() or G__get_window()
and G__put_window() first.

> > but at the minute my mind has gone blank as to the portable way to
> > replace that. I general audit of calls to system() would have caught
> > that if we're able to get round to doing it I suppose.
> 
> This might be priority to my testing via the GDF GRASS Tutorial, so I'll
> try to do that first.
> 
> Should all system calls be replaced by G_system ? Should any system /
> G_sytem calls be avoided ? Or should we check which system() calls use
> functions which might not exist in Windows ?

Avoid system() and G_system() equally. G_system() is almost identical
to system(), except that it appears to work around a signal handling
bug in some ancient system() implementations. Ditto for G_popen().

If you need to invoke an external program, G_spawn() or G_spawn_ex()
are preferable (although G_spawn_ex() hasn't been ported to Windows,
and hasn't really been tested). The advantage of the spawn.c functions
is that they don't involve a shell, so you don't have any issues
regarding quoting arguments.

But the only external programs which should be spawned are those which
are part of GRASS or were specified by the user. Anything else is
unlikely to exist on all platforms.

-- 
Glynn Clements <glynn at gclements.plus.com>