[GRASS-dev] [GRASS GIS] #2579: Specify command to be exectued as parameter of grass command

[GRASS GIS]

#2579: Specify command to be exectued as parameter of grass command
----------------------------------------------+-----------------------------
 Reporter:  wenzeslaus                        |       Owner:  grass-dev@…              
     Type:  enhancement                       |      Status:  new                      
 Priority:  normal                            |   Milestone:  7.1.0                    
Component:  Startup                           |     Version:  svn-trunk                
 Keywords:  batch job, GRASS_BATCH_JOB, init  |    Platform:  All                      
      Cpu:  Unspecified                       |  
----------------------------------------------+-----------------------------

Comment(by wenzeslaus):

 Replying to [comment:8 rkrug]:
 > Some remarks concerning the syntax:
 >
 > 1) I don't like the idea of having to repeat the mapset each time as it
 will require quite a bit of typing and possible errors in longer scripts.
 So the assumption to use the mapset which is in the rc file (i.e., if I am
 correct, the one used before), would be quite useful.
 >

 I have two use cases which were not mentioned. Testing framework which
 does not have particluar requirements on command line syntax but you run
 just one command/script, so you probably want to set
 `Database/Location/Mapset` in one command. And then it is
 [https://www.docker.com/ Docker] where setting of the
 `Database/Location/Mapset` in/with the command itself seems to be really
 important because you create a new instance with the command:

 {{{
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 .../script.sh with parameters
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 g.gisenv
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 r.mapcalc "aaa = 5"
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 r.info map=aaa
 }}}

 or following my initial suggestion:

 {{{
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 --batch .../script.sh with parameters
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 --batch g.gisenv
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 --batch r.mapcalc "aaa = 5"
 docker run user/grass-system grass70 --mapset
 ~/grassdata/nc_spm_08_grass7/user1 --batch r.info map=aaa
 }}}

 or similarly to Docker:

 {{{
 docker run user/grass-system grass70 run
 --mapset=~/grassdata/nc_spm_08_grass7/user1 .../script.sh with parameters
 docker run user/grass-system grass70 run
 --mapset=~/grassdata/nc_spm_08_grass7/user1 g.gisenv
 docker run user/grass-system grass70 run
 --mapset=~/grassdata/nc_spm_08_grass7/user1 r.mapcalc "aaa = 5"
 docker run user/grass-system grass70 run
 --mapset=~/grassdata/nc_spm_08_grass7/user1 r.info map=aaa
 }}}

 where `run` can be replaced by something different (`exec`, `batch`, `do`,
 `cmd`, `script`) in order to provide nice syntax also for the alternative
 usage described see below. Note that `--mapset` is not (does not have to
 be) mandatory, it can just use the last Mapset as stored in
 `$HOME/.grass7/rc`.

 Docker [https://docs.docker.com/reference/run/ general run syntax] is by
 the way:
 {{{
 docker run [OPTIONS] IMAGE[:TAG] [COMMAND] [ARG...]
 }}}

 Docker has the advantage that `IMAGE` is mandatory while in GRASS GIS,
 `Mapset` or `command` would be required (none, one, or both are possible).

 > 2) Instead of using the normal `grass` command, I would suggest to
 introduce a new command(e.g. {{{ggrassbatch}}}), which is taking only one
 parameter: the command to be executed including the parameter. So it could
 be used as
 >
 {{{
 grassbatch r.info
 }}}
 >
 This would be similar to `Rscript` command (as opposed to `R CMD` syntax).
 However, the nested commands seems to be quite common (although now I can
 remember just revision control systems and docker). But basically
 `grassbatch` and `grass batch` are very similar.

 > 3) The function {{{grassbatch}}} should accept, in addition to the
 normal grass commands, one more command named e.g. {{{set.mapset}}} which
 is only doing one thing, setting the mapset in the rc file, so this would
 be the mapset to be used for all following {{{grassbatch}}} commands,
 unless the mapset is changed.
 >
 > So a script could look as followed:
 {{{
 grassbatch set.mapset ~/grassdata/nc_spm_08_grass7/user1
 grassbatch .../test_script.sh
 grassbatch r.info
 grassbatch r.mapcalc "aaa = 5"
 }}}

 This goes to my other suggestion (in description or in [wiki:GSoC/2015
 #Neweasy-to-usecommandlineinterfaceforGRASSGIS GSoC ideas]), particularly
 a basic version of it. I think that there are good reasons to have both of
 them. Some use cases (Docker, testing framework, Cron jobs) push more for
 the single-command syntax, while user scripts and things which typically
 needs to import and export data (QGIS, WPS) would benefit more from this
 multi-command syntax. Where would you expect the current `GISRC` file to
 be? The runtime one is now in "`/tmp`" (`/tmp/grass7-user-number/gisrc`)
 while the initial one (from where `Database/Location/Mapset` is taken if
 not provided in command line) is in `$HOME/.grass7/rc`. My idea was to
 have it in the current directory (or possibly also specified in command
 line), so that it does not interfere with the one in `$HOME` which is the
 use case I expect.

 If we spend some time figuring out this, I think we can save a lot of time
 in a long run on the support, see for example recent post on the
 [http://lists.osgeo.org/pipermail/grass-user/2015-March/072068.html grass-
 user mailing list] ([http://osgeo-org.1560.x6.nabble.com/Using-GRASS-6
 -without-starting-it-Python-td5191943.html nabble link]).

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2579#comment:10>
GRASS GIS <http://grass.osgeo.org>