[GRASS-dev] Submitting module to addons - r.sundenoise - mentor required

Martin wrote:

In GRASS7 there is no extra support for shell scripts.

This is IMO a huge, huge mistake.

I am fine that all future run-time scripts shipped with GRASS 7+ be written
in python, but I think it is a serious strategic error to force users to
learn python and rewrite all their private & likely tested+trusted shell
scripts to a new language for what is essentially zero gain for them.
Encourage python for first-class addon scripts, yes; force it, no way.

I feel the same way about banning upper case option names in the parser.
Fine for official modules, but we should let the users do whatever they
please.

analogy: ensure that grass compiles with 'gcc -ansi' but don't mandate
that users' personal addon C programs do as well.

If users with a large investment/library of personal shell scripts will
have to rewrite all their scripts in python, and they already know some
Visual Basic, ... it's one thing for proprietary vendors to lock their
users in, it seems ridiculous to do the opposite and act to drive them
away.

So (IIU this C*), why should the removal of shell script support not be
reverted? What does it cost us to keep shell script support?**

[*] & I suspect I may not.
[**] loss of focus is a cost which must be balanced against continuity

Hamish

Hi,

2009/7/3 Hamish <hamish_b@yahoo.com>:

In GRASS7 there is no extra support for shell scripts.

This is IMO a huge, huge mistake.

I do not claim that it shouldn't be possible to run shell scripts in
GRASS7. Most of the restrictions in our lives are bad at the end;-)
Anyway I highly suggest to write new scripts in Python, see [1].
Probably it's personal point of view, but writing shell scripts was
always pain for me and I can hardly imagine person (without previous
scripting experience) who prefers to learn how to write shell scripts
rather then to learn Python. Python is quite easy language to learn
for newcomers. Shell scripts are simply not good choice for writing
sometimes quite complicated GRASS scripts.

Martin

[1] http://download.osgeo.org/grass/grass6_progman/pythonlib.html

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Martin,

the discussion here is not about whether to write NEW scripts as shell scripts
but whether anybody who has many shell scripts will have to rewrite
them into Python to be able to run them in GRASS7. Imagine you have 20 old,
stable, well tested scripts doing complex workflows and a lot of new work
to do, would you want to spend your time rewriting these old shell scripts
into Python or rather develop new capabilities? Some scripts may be worth
rewriting, some not. I think this is what Hamish had in mind.
BTW I am not the person who has lost of shell scripts so for me it does not matter,
but there are many people who do.
It may slow down adoption of GRASS7 and people may prefer to stick with
GRASS6*, rather than rewrite.

just a few words to support Hamish's view,

Helena

On Jul 3, 2009, at 12:26 PM, Martin Landa wrote:

Hi,

2009/7/3 Hamish <hamish_b@yahoo.com>:

In GRASS7 there is no extra support for shell scripts.

This is IMO a huge, huge mistake.

I do not claim that it shouldn't be possible to run shell scripts in
GRASS7. Most of the restrictions in our lives are bad at the end;-)
Anyway I highly suggest to write new scripts in Python, see [1].
Probably it's personal point of view, but writing shell scripts was
always pain for me and I can hardly imagine person (without previous
scripting experience) who prefers to learn how to write shell scripts
rather then to learn Python. Python is quite easy language to learn
for newcomers. Shell scripts are simply not good choice for writing
sometimes quite complicated GRASS scripts.

Martin

[1] http://download.osgeo.org/grass/grass6_progman/pythonlib.html

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Fri, Jul 3, 2009 at 6:26 PM, Martin Landa<landa.martin@gmail.com> wrote:

2009/7/3 Hamish <hamish_b@yahoo.com>:

In GRASS7 there is no extra support for shell scripts.

This is IMO a huge, huge mistake.

I do not claim that it shouldn't be possible to run shell scripts in
GRASS7.

Hi (just digging through too many emails almost randomly):

so do you *assume* that it still works in 7 or do shell scripts work?
The latter is the aim in my opinion.

If GRASS 7 would refuse to work with shell scripts I had to stick
with GRASS 6 for my work since I have hundreds of them including
very complex workflows. Most likely I'll switch to Python later this
year but certainly I won't rewrite working scripts if there is no need.

So, just confirm that my existing scripts still run [1] and I am happy
supporter of a "Python preferred" policy for GRASS 7.

cheers
Markus

Hamish wrote:

So (IIU this C*), why should the removal of shell script support not be
reverted? What does it cost us to keep shell script support?**

[*] & I suspect I may not.

The "support" which has been removed is limited to the build system.

If you include Script.make, the directory must contain $(PGM).py or
you get an error.

People are free to script GRASS commands in whatever language they
choose, but shell scripts don't belong in the GRASS 7 repository, so
there's no need for the build system to provide any support for them.

If something doesn't work unless you install /bin/sh and a dozen other
Unix utilities, that's a critical bug. Ditto for anything which
doesn't work if $GISBASE or GISDBASE contain spaces.

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