[GRASS-dev] using G_parser() --script in the wild

[Glynn Clements]

Hamish wrote:

> > > if [ "$GIS_FLAG_G" -eq 1 ] ; then
> > >     gflag="-g"
> > > else
> > >     gflag=""
> > > fi
> > > if [ -n "$GIS_OPT_AFCOL" ] ; then
> > >     afcol="afcol=\"$GIS_OPT_AFCOL\""
> > > else
> > >     afcol=""
> > > fi
> > > [...]
> > > exec d.path $gflag $afcol [...]
> > 
> > That works; it's just ugly. The fact that afcol, abcol and ncol need
> > special treatment stands out, and lead me to consider whether there's
> > a better solution.
> 
> why do the column name options need special treatment?

Because their default values are NULL pointers, which cannot be
specified via the command line.

For all of the other cases, we can specify the option along with its
default value.

> none of d.path's other options should contain spaces or special chars,
> so I don't think the quoting is critical.

Oh, we could treat all of the options the same as afcol= etc, but
that's more code, and unnecessary.

> If I quote the column options on the exec line I get this error:
> 
> if [ -n "$GIS_OPT_AFCOL" ] ; then
>     opt_afcol="afcol=$GIS_OPT_AFCOL"
> else
>     opt_afcol=""
> fi
> 
> [...]
> 
> exec d.path $flag_g $flag_b \
> 	"$opt_map" "$opt_type" \
> 	"$opt_alayer" "$opt_nlayer" \
> 	"$opt_afcol" "$opt_abcol" "$opt_ncol" \
> 	"$opt_color" "$opt_hcolor" "$opt_bgcolor"
> 
> 
> "Sorry <> is not a valid option",  followed by G_usage().

A pointer to an empty string (i.e. with NUL as the first byte) isn't
the same as a NULL pointer, and an empty string isn't a valid value
for the "afcol=" option.

The other options are either required or have a default value which
isn't a NULL pointer. E.g. type= defaults to "line,boundary"; if the
type= option isn't passed to the script, then:

	d.vect ... type=$GIS_OPT_TYPE

has the same effect as simply not passing the type= option; both will
result in type->answer pointing to "line,boundary".

However, for options whose default value is a NULL pointer, using

	d.vect ... afcol= ...

isn't the same as omitting it. Omitting it will result in
afcol->answer being NULL, while "afcol=" with an empty value will
result in afcol->answer pointing to an empty string.

> anyway, any problems with the attached script?

The changes will work, but aren't necessary; they just increase the
size of the script without changing its behaviour.

>  will column names require quoting? (e.g. column="Jane's Data")
>  or is that illegal SQL?

SQL column names are limited to alphanumerics and underscore.

-- 
Glynn Clements <glynn at gclements.plus.com>