Add batch job example without path

[jidanni]

On https://grass.osgeo.org/grass79/manuals/grass7.html all the batch job examples have

/path/to/grassdata/test1/PERMANENT/

in them. Please add at least one simple example,

grass --exec v.info map=abc

without it too. Works just fine.

[wenzeslaus]

Actually, I did not include it into documentation intentionally, but did not disable it - a dirty trick. I don't know if it is a good idea to do this, but it might be useful for some. Generally speaking, why would you like to run a batch job with whatever was the last used mapset? Of course, --exec is meant to be used more broadly than just batch jobs, but still it seems to me that specifying full path is appropriate.

If you would be using GRASS GIS only with --exec, this may not work as expected because --exec actually does not save the path (to a file in ~/.grass7), so the next call is using path from an interactive session (in GUI or with --text).

What you can do now is a workflow like this:

grass grassdata/location/mapset -c EPSG:3358 -e
grass grassdata/location/mapset --exec r.import input=some_image.tif output=some_image
grass grassdata/location/mapset --exec r.info some_image
grass grassdata/location/mapset --exec r.mapcalc "improved_image = 5 * some_image"
grass grassdata/location/mapset --exec r.out.gdal input=improved_image output=.../improved_image.tiff

I think you are suggesting you want a workflow like this:

grass grassdata/location/mapset -c EPSG:3358 -e
grass --exec r.import input=some_image.tif output=some_image
grass --exec r.info some_image
grass --exec r.mapcalc "improved_image = 5 * some_image"
grass --exec r.out.gdal input=improved_image output=.../improved_image.tiff

It seemed to be that --exec probably should not behave like that, so e.g. in #2579 (under Additional ideas), I suggested a subcommand directory-oriented interface using a hidden file in the current directory (but which still keeps the "connect to any grassdata/location/mapset" concept):

grass init grassdata/location/mapset EPSG:3358
grass lock grassdata/location/mapset
grass exec r.import input=some_image.tif output=some_image
grass exec r.info some_image
grass exec r.mapcalc "improved_image = 5 * some_image"
grass exec r.out.gdal input=improved_image output=improved_image.tif
grass unlock

(The above is just an idea for now, init and lock could be merged, grassdata/location/mapset could default to something in init and use more convention over configuration in lock, unlock could be renamed...)

[jidanni]

OK first let me say that it should be documented that by not including a PATH the user may think he is actually able to "test in a pristine vanilla environment" but in fact he is actually just using the previous environment under the hood... unless he uses --exec...

[jidanni]

All this is getting too complex for me. Maybe document a way to use a /dev/null mapset so the user can run some e.g., g.gisenv or whatever queries if he wants, without worrying that they access or store to any particular mapset.

[wenzeslaus]

Replying to jidanni:

...user may think he is actually able to "test in a pristine vanilla environment" ... All this is getting too complex for me.

You are actually right. The documentation assumes that you start with --exec etc. after you have some knowledge of GRASS GIS already. That's wrong assumption and unnecessary requirement. I can see now that it is actually misleading.

I don't have a clear plan now for improving it, so any suggestions or PRs are as always welcome.

Maybe document a way to use a /dev/null mapset so the user can run some e.g., g.gisenv or whatever queries if he wants, without worrying that they access or store to any particular mapset.

There is --tmp-location (created in a temporary database/directory) which allows you to run commands without creating any location (and thus mapset) permanently (again the documentation assumes you know why it is it useful). One use of specifically --tmp-location XY is running modules such as g.manual or g.extension which don't work with any data. General use is running scripts and using GRASS GIS as a processing backend.

A temporary mapset (--tmp-mapset) would make sense too for same cases (see GSoC 2019 New Easy CLI Idea for the suggestion).