Hi

2015-09-14 23:51 GMT+02:00 Vaclav Petras <[email protected]>:
>
> On Mon, Sep 14, 2015 at 4:53 PM, Markus Neteler <[email protected]> wrote:
>>
>>
>> If the point of using that env var is to simply suppress the warning
>> in the upper case, then maybe G_suppress_warnings(1) is better?
>> Something like
>>
>> Index: lib/python/temporal/c_libraries_interface.py
>> ===================================================================
>> --- lib/python/temporal/c_libraries_interface.py    (revision 66229)
>> +++ lib/python/temporal/c_libraries_interface.py    (working copy)
>> @@ -294,7 +294,9 @@
>>              char_list = ""
>>              mapset = mapsets[count]
>>
>> +            libgis.G_suppress_warnings(1)
>>              permission = libgis.G_mapset_permissions(mapset)
>> +            libgis.G_suppress_warnings(0)
>>              in_search_path = libgis.G_is_mapset_in_search_path(mapset)
>>
>> I see it used in various raster modules.
>> What do you think?
>
> Well, if it is in multiple raster modules then it is a conceptual problem.
> Either the modules are doing something wrong or the right API is missing for
> that case.

I am not sure about this, but i have the feeling that the
mapset/permission API needs some love. It was not obvious for me, that
i need to call
G_get_mapset_name(0) to initialize an internal static list so that
G_is_mapset_in_search_path() will work. That is bad design and not
well documented.
Regarding G_mapset_permissions(), it only checks the owner but not the
permission for groups and other, hence it is only used to determine if
the mapset exists
as in g.list.

However, the warning about mapset access is generated in
"lib/temporal/lib/connect.c" which checks the output of
G_mapset_permissions2. I will remove this check
since only the owner is checked, not access permissions.

Ciao
Sören

>
> Vaclav
>
> _______________________________________________
> grass-dev mailing list
> [email protected]
> http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev

Reply via email to