In <http://grass.osgeo.org/grass71/manuals/g.parser.html>, "Notes":
--%<---
...individual comma separated identities for an option named "input" can be parsed with the following Bash shell code:
IFS=,
for opt in $GIS_OPT_INPUT ; do
... "$opt"
done
--->%--
Doesn't this require to set the IFS back to what it was? Maybe note it too?
I've been trapped in this (as usual, not being careful): <http://unix.stackexchange.com/a/98853/13011>\.
Nikos
Nikos Alexandris wrote:
--%<---
...individual comma separated identities for an option named "input"
can be parsed with the following Bash shell code:IFS=,
for opt in $GIS_OPT_INPUT ; do
... "$opt"
done
--->%--Doesn't this require to set the IFS back to what it was? Maybe note it
too?
Yes.
Or even just remove the reference to bash from the 7.x documentation.
If you're using 7.x, Python is almost mandatory, so why would you
write bash scripts?
--
Glynn Clements <glynn@gclements.plus.com>
Nikos Alexandris wrote:
--%<---
...individual comma separated identities for an option named "input"
can be parsed with the following Bash shell code:IFS=,
for opt in $GIS_OPT_INPUT ; do
... "$opt"
done
--->%--Doesn't this require to set the IFS back to what it was? Maybe note it
too?
Glynn Clements wrote:
Yes.
Or even just remove the reference to bash from the 7.x documentation.
If you're using 7.x, Python is almost mandatory, so why would you
write bash scripts?
I recently switched to all-Python :-). Yet, incomplete notes still remain incomplete.
By the way, in Python, is .split(',') the only way to seprate multiple (input) identities in a list/dictionary? Shouldn't the parser, with the option "multiple: yes" do this already for the scripter?
For example, in
#%option
#% key: msx
#% type: string
#% gisprompt: old,double,raster
#% description: Low resolution multi-spectral image(s)
#% required: yes
#% multiple: yes
#%end
it would be nice to have a new list after
newlist = options['msx']
Or would this cause trouble?
Thank you,
Nikos
On Tue, Nov 4, 2014 at 1:58 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:
Nikos Alexandris wrote:
> --%<---
> ...individual comma separated identities for an option named "input"
> can be parsed with the following Bash shell code:
>
> IFS=,
> for opt in $GIS_OPT_INPUT ; do
> ... "$opt"
> done
> --->%--
>
> Doesn't this require to set the IFS back to what it was? Maybe note it
> too?Yes.
Or even just remove the reference to bash from the 7.x documentation.
If you're using 7.x, Python is almost mandatory, so why would you
write bash scripts?
In what sense mandatory? I see it to be highly desirable, especially if you
want to share your scripts. But not everybody is well versed in python, and
the option to write bash scripts will remain useful I am sure to part of
the users. Why not maintaining some useful references?
--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Nikos Alexandris wrote:
By the way, in Python, is .split(',') the only way to seprate
multiple (input) identities in a list/dictionary? Shouldn't the parser,
with the option "multiple: yes" do this already for the scripter?
grass.script.parser() doesn't examine the script's interface; it just
invokes g.parser and parses the result.
At present, having the parser examine the interface would require
either replicating the g.parser logic within grass.script, or invoking
the module with --interface-description and parsing the resulting XML.
If we want to relieve the scripts of the burden of parsing option
values, it would make more sense to extend g.parser to include type
information in the data it sends back to the script.
The question is, how much type information do we want to use. There
are at least 3 factors:
1. opt->multiple => convert the value to a list.
2. opt->type => convert value(s) to int/float.
3. opt->key_desc includes commas => convert values to tuples
--
Glynn Clements <glynn@gclements.plus.com>
Paulo van Breugel wrote:
> Or even just remove the reference to bash from the 7.x documentation.
> If you're using 7.x, Python is almost mandatory, so why would you
> write bash scripts?In what sense mandatory?
Mandatory in the sense that, if you don't have Python installed, a
large chunk of GRASS (wxGUI, scripts, temporal framework) will be
unavailable to you (and you'll have to create your own GRASS sessions,
because the "grass70" startup script is a Python script).
GRASS modules can be executed from any language which has the
necessary primitives (system() or whatever).
The main reason people write Bourne shell scripts is that it's the one
language interpreter that's guaranteed to be present on any Unix
system. It's certainly not because it's a nice language for writing
programs (the actual language is inherently compromised by the need
for it to be usable as an interactive shell).
But if you're going to be assuming the existence of GRASS 7 modules,
Python is even more likely to be installed than a Bourne shell
(Windows installations typically won't have a Bourne shell).
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Nov 5, 2014 at 12:22 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:
Paulo van Breugel wrote:
> > Or even just remove the reference to bash from the 7.x documentation.
> > If you're using 7.x, Python is almost mandatory, so why would you
> > write bash scripts?
>
> In what sense mandatory?Mandatory in the sense that, if you don't have Python installed, a
large chunk of GRASS (wxGUI, scripts, temporal framework) will be
unavailable to you (and you'll have to create your own GRASS sessions,
because the "grass70" startup script is a Python script).
Ah, sorry, I misread your line as it being mandatory to have scripts
written in python.
GRASS modules can be executed from any language which has the
necessary primitives (system() or whatever).The main reason people write Bourne shell scripts is that it's the one
language interpreter that's guaranteed to be present on any Unix
system. It's certainly not because it's a nice language for writing
programs (the actual language is inherently compromised by the need
for it to be usable as an interactive shell).
I am sure python is a nicer language, but right now for me (and the same
might be true for others) bash scripting is easier (not that I am any good
in bash scripting, I just have very little experience in python).
Personally I am working on my Python skills, but that is a slow process.
For me the most useful documentation I have used in that respect is
explanations how to 'translate' bask to python (can't remember right now
which webpage that was though).
But if you're going to be assuming the existence of GRASS 7 modules,
Python is even more likely to be installed than a Bourne shell
(Windows installations typically won't have a Bourne shell).
Yes, perfectly clear, thanks for the explanation (and sorry for my sloppy
reading of the original statement).
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, Nov 5, 2014 at 6:35 AM, Paulo van Breugel <p.vanbreugel@gmail.com>
wrote:
The main reason people write Bourne shell scripts is that it's the one
language interpreter that's guaranteed to be present on any Unix
system. It's certainly not because it's a nice language for writing
programs (the actual language is inherently compromised by the need
for it to be usable as an interactive shell).I am sure python is a nicer language, but right now for me (and the same
might be true for others) bash scripting is easier (not that I am any good
in bash scripting, I just have very little experience in python).
Personally I am working on my Python skills, but that is a slow process.
For me the most useful documentation I have used in that respect is
explanations how to 'translate' bask to python (can't remember right now
which webpage that was though).
I was already writing this to similar discussion here. My rule is that
anything which is not trivial should be in Python, not Bash. Although I
know Python more than Bash, trivial things are just easier in Bash but
anything which has if statements, more complicated for loops or is longer
than 10 or 20 lines should be in Python. Moreover, with Python, you can run
the script on MS Windows if need and more importantly, you have the
potential* of including it into GRASS addons to share this with broader
community because this is how we add new features, right?
* Difference between script and real GRASS module is of course the
interface and more general approach to the problem but it is easier to just
add this than rewrite a Bash script to Python (and then add what's needed
for GRASS module).
On Wed, Nov 5, 2014 at 3:56 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Wed, Nov 5, 2014 at 6:35 AM, Paulo van Breugel <p.vanbreugel@gmail.com>
wrote:The main reason people write Bourne shell scripts is that it's the one
language interpreter that's guaranteed to be present on any Unix
system. It's certainly not because it's a nice language for writing
programs (the actual language is inherently compromised by the need
for it to be usable as an interactive shell).I am sure python is a nicer language, but right now for me (and the same
might be true for others) bash scripting is easier (not that I am any good
in bash scripting, I just have very little experience in python).
Personally I am working on my Python skills, but that is a slow process.
For me the most useful documentation I have used in that respect is
explanations how to 'translate' bask to python (can't remember right now
which webpage that was though).I was already writing this to similar discussion here. My rule is that
anything which is not trivial should be in Python, not Bash. Although I
know Python more than Bash, trivial things are just easier in Bash but
anything which has if statements, more complicated for loops or is longer
than 10 or 20 lines should be in Python.
I am actually using R for that right now, either directly in R (using the
spgrass6 interface or the system() interface in R. Or in a few cases I use
a bash script that gets the variables and then runs a R script. Should
learn how to replace R with python, or where that is not possible, how to
interact with R from within a python script. Any good documentation on that
(haven't looked terribly hard yet, so sorry if I overlooked the obvious)?
Moreover, with Python, you can run the script on MS Windows if need and
more importantly, you have the potential* of including it into GRASS addons
to share this with broader community because this is how we add new
features, right?* Difference between script and real GRASS module is of course the
interface and more general approach to the problem but it is easier to just
add this than rewrite a Bash script to Python (and then add what's needed
for GRASS module).
On Wed, Nov 5, 2014 at 12:34 PM, Paulo van Breugel <p.vanbreugel@gmail.com>
wrote:
Any good documentation on that (haven't looked terribly hard yet, so sorry
if I overlooked the obvious)?
This is a bit issue, there is no tutorial and documentation is really basic
[1]*. There is a lot of information on wiki [4].
* PyGRASS [3] has better documentation then standard scripting interface
[2].
[1] http://grass.osgeo.org/grass71/manuals/libpython/
[2] http://grass.osgeo.org/grass71/manuals/libpython/script.html
[3] http://grass.osgeo.org/grass71/manuals/libpython/pygrass_index.html
[4] http://grasswiki.osgeo.org/wiki/Python