[GRASS-dev] G.proj requirements?

[Paul Kelly]

On Wed, 20 Dec 2006, Hamish wrote:

> Paul Kelly wrote:
>> The other option is to keep a lookout after changing it for
>> badly-behaved  modules that don't delete their temp files. Also I
>> don't think it's unreasonable for temp files to be left undeleted if
>> a module crashes?
>
> While not important for native windows, e.g. d.text (and d.graph?) can
> keep tmp files around so the command will survive d.redraw (if input was
> piped from stdin). These are then removed when the .tmp dir is flushed
> when GRASS exits/restarts.

Hmm, that sounds like a definite issue. Perhaps those modules could be 
changed to use the new G_tempfile_in_mapset() or whatever we call it? I 
just thought of another reason not to put the tempfiles in the session 
directory---if the GRASS libraries are being called from e.g. QGIS or GDAL 
to read a GRASS file then there won't be an existing GRASS session so 
that wouldn't work.

> Generally tmp files should be removed, but enforcing it is a pain for
> debugging and development.

Modules that require temp files to stick around should specifically create 
them in the current mapset; others should carry on using G_tempfile(). How 
does that sound.

Paul