Script engine - was: Re: [GRASS5] Driver Update

[Markus Neteler]

On Wed, Jun 27, 2001 at 12:20:46AM +0100, Glynn Clements wrote:
[...]
> > Thanks for pointing this out. The general problem in GRASS is
> > the odd mixture of old and new code... as we all know already.
> 
> Having said that, all scripts suffer from the drawback that they don't
> generally behave like other GRASS programs. I've recently been
> thinking about creating a utility specifically for running scripts.
> 
> One possibility would be a modified tclsh which includes key libgis
> functions (e.g. G_parser) as tcl commands. However, I don't know
> whether tcl is sufficiently widely available to be able to justify
> using it in place of the Bourne shell.
> 
> Another possibility would be a simple utility which could be invoked
> by shell scripts to handle the G_parser() stuff before re-invoking the
> script with a full argument list (unless "help" or "--int*-desc*" were
> used). However, this could still leave incompatibilities between C
> programs and scripts in other areas.
> 
> Comments?
> -- 
> Glynn Clements <glynn.clements at virgin.net>


...for platform independency and due to the unknown future of tcl/tk I
vote for option (2): a simple utility which could be invoked by shell
scripts to handle the G_parser() stuff before re-invoking the script.

If an C-based (?) environment would be present to support own script
developments, less later work to reach consistency is to be expected.
Even other GIS have script-builders, so why not GRASS. Maybe some
compulsory definitions at top of the script could be interpreted to
define the settings for G_parser, description text etc. Then the
script stuff follows.

Markus