Luca Palmeri <lpalmeri@ux1.unipd.it> writes:
Ok now I understand. Each user has his own mapset and can work only on
that.
Last time I looked (which is a couple of releases ago) users may only _write_ to
their own mapsets. They typically can _read_ both the PERMANENT mapset, and
other users' mapsets in the same location, unless those users have explicitly
blocked read access. See the docs for g.access and g.mapsets.
My concern was on using multiple grass shells on different mapsets at
the
same time from different machines in NFS. Given that grass do not allow
the same
user to run multiple session I was thinking that one solution was to use
different users in the same location, all accessing to the same mapsets.
That restriction on multiple sessions can be bypassed by a simple edit of
etc/GIS.sh, by removing all the locking code. Alternatively, bypass that
front-end file completely by simply issuing Grass commands at the Unix prompt
(but you need to set a few environment variables in order to be able to do
this).
Obviously, if you are attempting to create some generic Grass user in a
distributed environment, then users will potentially be able to corrupt each
others' files, as well as a few other problems to do with maintaining consistent
regions and monitor selections.
--
Conn V Copas
Information Technology Division
Defence Science and Technology Organisation
PO Box 1500
Salisbury tel: +61 (0)8 825 95349
SA 5108 fax: +61 (0)8 825 95589
Australia e-mail: Conn.Copas@dsto.defence.gov.au
------------------------------------------------------