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

Vaclav Petras wenzeslaus at gmail.com
Wed Nov 5 06:56:53 PST 2014


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. 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/46f9acd7/attachment.html>


More information about the grass-dev mailing list