[GRASS-dev] [GRASS GIS] #3632: Add a function to read parameters from a file to the parser

[GRASS GIS]

#3632: Add a function to read parameters from a file to the parser
-------------------------+-------------------------------------------------
  Reporter:  wenzeslaus  |      Owner:  grass-dev@…
      Type:              |     Status:  new
  enhancement            |
  Priority:  normal      |  Milestone:  8.0.0
 Component:  Parser      |    Version:  unspecified
Resolution:              |   Keywords:  g.parser options parameters file
       CPU:              |  long CLI
  Unspecified            |   Platform:  Unspecified
-------------------------+-------------------------------------------------

Comment (by mmetz):

 Replying to [comment:3 wenzeslaus]:
 > Replying to [comment:2 mmetz]:
 > >
 > > Using the example
 > > {{{
 > > r.slope.aspect elevation=dtm slope=dtm_slope aspect=dtm_aspect -n
 > > }}}
 > > what is the advantage of the proposed approach over a file that
 contains exactly this line and executing this file? This is already
 working and handled by the OS.
 >
 > I'm thinking about these three points:
 >
 > 1) There is no command line length limitation as the line or lines are
 processed directly by the parser.
 >
 > When I have a long r.series input:
 >
 > {{{
 > > r.series in=map1900,map1901,...,map2100 out=slope meth=slope
 > }}}
 >
 > I need to switch to `file` instead of `input`.
 >
 >
 > {{{
 > > cat input.txt
 > map1900
 > map1901
 > ...
 > map2100
 > > r.series file=input.txt out=slope meth=slope
 > }}}
 >
 > That of course assumes that `file` was implemented. In case of having
 the parameter file, I need to switch to that while still using `input`.

 You need to switch in any case. It is easier to create a list input names
 (`glist ... output=mylist`) than to create a parameter file.
 >
 > 2) The scripting is replaced with configuration. This "command line
 scripting" is OS-depended. You want a short line, but backslashes won't
 work in GUI Console (and on MS Win?). Escaping is done in different ways.

 I am referring to your example
 > > {{{
 > > r.slope.aspect elevation=dtm slope=dtm_slope aspect=dtm_aspect -n
 > > }}}
 which works on any OS.

 > In other words, the format is actually not well defined, so unless you
 already know "command line scripting" on your OS, this will be cumbersome.
 Another syntax related thing are comments which again could have a clearly
 defined syntax (`#` in Bash versus `REM` in CMD).

 scripting is of course OS dependent and not related to the proposed
 parameter file option

 >
 > So the following ways of storing the parameters as a command with
 indentation and backslash which will work well in unix-like command line
 but not necessarily elsewhere (which is something we need to explain to
 the user),

 I am referring to your example
 > > {{{
 > > r.slope.aspect elevation=dtm slope=dtm_slope aspect=dtm_aspect -n
 > > }}}
 no indentation or backslash

 > 3) This untangles the module from its parameters (splits the "command"
 into module name and parameters).

 The history would no longer make sense because the parameters of the
 called modules are no longer recorded in history. In the meantime, the
 parameter files could be altered, moved, or deleted.

 In this context, calling a module and creating a script for a specific OS
 must not be mixed.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/3632#comment:5>
GRASS GIS <https://grass.osgeo.org>