Opened 5 years ago

Last modified 5 years ago

#3967 new enhancement

Add batch job example without path

Reported by: jidanni Owned by: grass-dev@…
Priority: trivial Milestone: 7.8.3
Component: Docs Version: unspecified
Keywords: grass.py exec CLI init Cc:
CPU: Unspecified Platform: Unspecified

Description

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.

Change History (5)

comment:1 by wenzeslaus, 5 years ago

Keywords: grass.py exec CLI init added

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...)

comment:2 by jidanni, 5 years ago

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...

comment:3 by jidanni, 5 years ago

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.

in reply to:  3 comment:4 by wenzeslaus, 5 years ago

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).

Last edited 5 years ago by wenzeslaus (previous) (diff)

comment:5 by neteler, 5 years ago

Milestone: 7.8.3
Note: See TracTickets for help on using tickets.