#1660: RFE: add new batch= command line option to main grass7 startup script
-----------------------------+----------------------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Startup | Version: svn-trunk
Keywords: GRASS_BATCH_JOB | Platform: All
Cpu: All |
-----------------------------+----------------------------------------------
Hi,
to make running GRASS_BATCH_JOBs a bit easier to use (and to avoid the
common mistake of not `unset`ing it after), it would be nice if the
main grass7 startup script could parse the command line argv options for
batch=, check that the script exists and is executable, then use it
instead of looking for a GRASS_BATCH_JOB enviro variable?
perhaps with that done GRASS_BATCH_JOB could be retired for GRASS 7.0?
(or would there still be some reason to keep it as an alternate method?)
#1660: RFE: add new batch= command line option to main grass7 startup script
-----------------------------+----------------------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Startup | Version: svn-trunk
Keywords: GRASS_BATCH_JOB | Platform: All
Cpu: All |
-----------------------------+----------------------------------------------
Comment(by wenzeslaus):
It would be nice if it would support not only scripts but any executable
including GRASS modules.
Also the question is how the parameters would be passed to the process.
The whole command in one parameter (the question is how quoted parameters
would be passed):
{{{
grass --batch="g.region -p"
}}}
Alternatively, parameters after `--batch=...` can be passed to the
subprocess.
{{{
grass --batch=g.region -p
}}}
> perhaps with that done GRASS_BATCH_JOB could be retired for GRASS 7.0?
(or would there still be some reason to keep it as an alternate method?)
The only reason to keep it would be backward compatibility and it think
this is not concern here considering the audience (size and type). Perhaps
both can be for some time in trunk but not in release.
#1660: RFE: add new batch= command line option to main grass7 startup script
--------------------------+-------------------------------------------------
Reporter: hamish | Owner: grass-dev@…
Type: enhancement | Status: closed
Priority: normal | Milestone: 7.0.0
Component: Startup | Version: svn-trunk
Resolution: duplicate | Keywords: GRASS_BATCH_JOB
Platform: All | Cpu: All
--------------------------+-------------------------------------------------
Changes (by wenzeslaus):
* status: new => closed
* resolution: => duplicate
Comment:
Replying to [comment:1 wenzeslaus]:
> It would be nice if it would support not only scripts but any executable
including GRASS modules.
>
> Also the question is how the parameters would be passed to the process.
>
> The whole command in one parameter (the question is how quoted
parameters would be passed):
{{{
grass --batch="g.region -p"
}}}
Passing parameters is crucial enhancement in comparison to
`GRASS_BATCH_JOB`. However, this syntax would not work for more
complicated cases due to parsing issues.
>
> Alternatively, parameters after `--batch=...` can be passed to the
subprocess.
>
{{{
grass --batch=g.region -p
}}}
This is strange hybrid which is not necessary. `grass7` command is not
using syntax with `=` (unlike modules) and separate module parameters
would anyway break the rules. See #2579 for better suggestions.
>
>
> > perhaps with that done GRASS_BATCH_JOB could be retired for GRASS 7.0?
(or would there still be some reason to keep it as an alternate method?)
>
> The only reason to keep it would be backward compatibility and it think
this is not concern here considering the audience (size and type). Perhaps
both can be for some time in trunk but not in release.
`GRASS_BATCH_JOB` is part of 7.0.0, so it will stay there. But once this
is implemented, I don't see any advantage in `GRASS_BATCH_JOB`.
Closing this as a duplicate of #2579 (which I opened not remembering this
one). Leaving the other one as primary as the discussion is more developed
there (including patch).