[GRASS-dev] g.parser: Note on setting bash' IFS to parse separate identities

Paulo van Breugel p.vanbreugel at gmail.com
Wed Nov 5 09:34:13 PST 2014


On Wed, Nov 5, 2014 at 3:56 PM, Vaclav Petras <wenzeslaus at gmail.com> wrote:

>
> On Wed, Nov 5, 2014 at 6:35 AM, Paulo van Breugel <p.vanbreugel at 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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141105/04a11d48/attachment-0001.html>


More information about the grass-dev mailing list