RFE: add new batch= command line option to main grass7 startup script

[hamish]

Hi,

to make running GRASS_BATCH_JOBs a bit easier to use (and to avoid the common :-) mistake of not unseting 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?)

thanks, Hamish

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

[wenzeslaus]

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