Hamish wrote: > Moritz: > > I imagine that you can create your own location by having a > > script create the location directory, the PERMANENT mapset > > directory and the PROJ_INFO, DEFAULT_WIND and PROJ_UNITS > > files, or ?
You can. It would be easier to use an existing location, although this gets problematic for concurrent use. OTOH, a script could just make the top-level directory then extract the files from a tar/zip/etc file. > So what we need is a wrapper script that will create a dummy location/ > mapset in /tmp/ and run 'grass64 + g.proj -c' via a GRASS_BATCH_JOB (be > it .sh or .py). Not really. The grass64 script should be reserved for interactive startup. Scripts should set up their environment themselves; it isn't rocket science. > Any hints on how the man page parts of the build process > accomplish this? It points GISRC at the dist.<arch>/demolocation/.grassrc64 file, which uses dist.<arch>/demolocation/PERMANENT as the mapset. > To give access to g.parser, could the enviro vars be set up at the start > of the script so the thing could bootstrap itself? ie can we somehow > find a way to use the GRASS parser from the non-GRASS command line? I'm > guessing this is not easy due to the 2-pass way g.parser works, but a > smart devel might be able to make it happen somehow. Just set the environment variables. Personally, I suggest packaging GRASS so that the environment variables are set system wide from e.g. /etc/env.d/90grass (or whatever mechanism a particular distribution uses for package-specific environment settings). Users would only need to run the grass64 script if they wanted to start a second session. -- Glynn Clements <[email protected]> _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
