[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:  closed
  Priority:  normal       |  Milestone:  7.1.0
 Component:  Startup      |    Version:  svn-trunk
Resolution:  fixed        |   Keywords:  batch job, GRASS_BATCH_JOB, init
       CPU:  Unspecified  |   Platform:  All
--------------------------+----------------------------------------------
Changes (by wenzeslaus):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Parsing of parameters should be refactored and improved and behavior when
 both `GRASS_BATCH_JOB` and `--exec` are used should be revised but the
 goal of this ticket was fulfilled. Closing as fixed. This shouldn't be
 backported to 7.0 branch (or at lease not any time soon) because it makes
 a lot of changes to a crucial code.

 Two other major issues were discussed together with this topic and these
 are //direct execution with imports// (`grass run r.slope.aspect
 elevation=file:///path/to/file.tiff...`) and //subcommand interface//
 (`grass start .../mapset; grass run r.slope.aspect...;`). The later should
 be easy to implement now. The hardest part in implementation is to read
 the "gisrc" file from current directory and decide the name for the `run`
 subcommand considering newly added `--exec` and potential //direct
 execution with imports// which would probably need another subcommand or
 parameter. How to call individual interfaces (including this one) should
 be revised as well.

 There is an unresolved issue with code duplication between
 `lib/init/grass.py` and `lib/python/script/setup.py`. There is some code
 duplication now but `script.setup(.init)` would benefit from some code in
 `grass.py` which would even increase the duplication. The question is if
 we can safely import `grass.script.setup` during startup in `grass.py`.

 Finally, to make this `--exec` interface really convenient (and script
 universal), it would be nice to ensure that on system there is `grass`
 available on path. This is true for Linux distributions but it is not true
 for MS Windows. Perhaps it also needs to be documented more including
 distinction between `grass`, `grass7` and `grass71`.

 None of the issues above has currently its ticket.

 //Direct execution with imports// GSoC idea:
 * wiki:GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS

 //Subcommand interface// mailing list discussions:
 * [http://lists.osgeo.org/pipermail/grass-user/2015-June/072525.html
 Announcing new command line interface of `grass` program in trunk
 (Vaclav)]
  * [http://lists.osgeo.org/pipermail/grass-user/2015-June/072529.html
 Announcing new command line interface of `grass` program in trunk
 (Rainer)]
  * [http://lists.osgeo.org/pipermail/grass-user/2015-June/072531.html
 Announcing new command line interface of `grass` program in trunk
 (Vaclav)]
  * [http://lists.osgeo.org/pipermail/grass-user/2015-June/072537.html
 Announcing new command line interface of `grass` program in trunk
 (Rainer)]
  * [http://lists.osgeo.org/pipermail/grass-user/2015-June/072540.html
 Announcing new command line interface of `grass` program in trunk
 (Pietro)]
 * [http://lists.osgeo.org/pipermail/grass-stats/2015-June/001532.html R
 interface to grass 7.1]
 * [http://lists.osgeo.org/pipermail/grass-dev/2015-February/073861.html On
 GSoC Proposal "New easy-to-use command line interface for GRASS GIS"
 (Moritz)]
  * [http://lists.osgeo.org/pipermail/grass-dev/2015-February/073867.html
 On GSoC Proposal "New easy-to-use command line interface for GRASS GIS"
 (Vaclav)]
 * [http://lists.osgeo.org/pipermail/grass-dev/2015-January/072979.html
 QGIS Processing & GRASS]

 Related tickets:
 * #2424
 * #2679
 * #2681
 * #2639
 * #2685
 * #2511
 * #2678

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