currently G_script() in GRASS 7 prints out a shell script template.
Should this be replaced by a Python script template or should have the
parser separate switches for shell/python/? script templates.
On Fri, Jul 10, 2009 at 11:01 AM, Martin Landa<landa.martin@gmail.com> wrote:
Hi,
currently G_script() in GRASS 7 prints out a shell script template.
Should this be replaced by a Python script template or should have the
parser separate switches for shell/python/? script templates.
Would it be possible to have G_python() additionally?
currently G_script() in GRASS 7 prints out a shell script template.
Should this be replaced by a Python script template or should have the
parser separate switches for shell/python/? script templates.
Just remove the final printf() so that it's language-agnostic; its
main purpose is to generate the #% lines.
> currently G_script() in GRASS 7 prints out a shell script template.
> Should this be replaced by a Python script template or should have the
> parser separate switches for shell/python/? script templates.
Markus Neteler wrote:
Would it be possible to have G_python() additionally?
besides the basic --script for the GUI menu structure, it would be nice
to also have:
--shell-script or --bourne-script
and
--python-script
which would modify script() to fill in the basic shebang and have to be
in grass to use this ### your code goes here ### stuff.
> > currently G_script() in GRASS 7 prints out a shell script template.
> > Should this be replaced by a Python script template or should have the
> > parser separate switches for shell/python/? script templates.
Markus Neteler wrote:
> Would it be possible to have G_python() additionally?
besides the basic --script for the GUI menu structure, it would be nice
to also have:
--shell-script or --bourne-script
and
--python-script
which would modify script() to fill in the basic shebang and have to be
in grass to use this ### your code goes here ### stuff.
I really don't see the point. It's not as if you can use the result
without some form of manual intervention.
And it's not like this feature will be heavily used; its only purpose
is for creating a script which acts as a wrapper around an existing
module.
Adding addtional features is likely to take more effort than it will
ever save.