[GRASS-dev] Re: testing native winGRASS

[Moritz Lennert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/03/07 15:48, Paul Kelly wrote:
> On Wed, 14 Mar 2007, Moritz Lennert wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 13/03/07 23:34, Paul Kelly wrote:
>>> Hello Moritz
>>>
>>> On Tue, 13 Mar 2007, 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...

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 ?

> 
> 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 ?

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF+BVZMiPFf/8qzFYRAq90AJ9Rsy9ML9EfO2bLNNX7LSonQVIPFQCePXT4
AswvK5NfCrCv3kDLRCJp8Lg=
=4voq
-----END PGP SIGNATURE-----