[GRASS-dev] grass and python

[Glynn Clements]

David Finlayson wrote:

> It is quite possible to initialize and run grass without Bash. I have a
> simi-working python script that fires up GRASS using IPython as it's shell.
> In fact, since Python abstracts os calls such as creating temp files,
> setting environment variables, etc, it is actually much easier to write a
> cross-platform initialization script in Python than in Bash. HOWEVER (and
> this is big), if you do not have a traditional unix shell running grass,
> none of the nearly 100 or so scripts that are distributed with GRASS---and
> that depend on bash---will work.
> 
> Many standard GRASS commands are really shell scripts. Every single one of
> them will need to be ported to your new shell if this isn't compatible with
> Bash. I stopped working on this when I realized how disruptive this was
> going to be (and how unlikely this would be supported by the core GRASS
> community). I don't think the vast majority of GRASS developers want to move
> to a Python environment (or Ruby or Perl or cmd.exe, etc). So, basically,
> this is an idea dead-on-arrival. It would amount to a fork of GRASS and new
> users would have a terrible time figuring out which shell they were supposed
> to be using for each script.
> 
> I think that GRASS is intimately tied to a Posix-compliant shell. There
> needs to be a standard macro-language for scripting and Bash seems as good
> as any.

The one thing that Bourne shell (not necessarily bash) has going for
it is its install base. It exists on every Unix-like system, and on
non-Unix systems, it's as widespread as any other portable interpreted
language.

Personally, I'd be more than happy to drop Bourne shell in favour of
some other language, *if* there was some other language which was
sufficiently trivial to install and use on systems which didn't
already have it.

The biggest problem is Windows, specifically the fact that it doesn't
support scripts which specify their interpreter in the file itself
(i.e. the #! mechanism on Unix); the interpreter has to be specified
through the file's extension.

This isn't insurmountable. We could force the appropriate extensions
onto script files for Windows installations, and you can use the
PATHEXT variable to eliminate the need to type the extension.

However, I don't know whether this works through system()-type
functions in other languages, or whether you would have to include the
script's extension there. Requiring scripts (or compiled programs) to
conditionally include the extension only on Windows would be a
nuisance, and unconditionally adding an extension would be a nuisance
on Unix systems.

If anyone can find a real language which is "good enough" on all of
Unix, Windows (Cygwin and native) and OSX, I'll quite happily rewrite
all of GRASS' shell scripts.

Apart from the fact that Bourne shell basically sucks in every way
imaginable as a programming languague, it's further hampered by the
fact that all of the common Windows ports try to provide some degree
of Unix compatibility (e.g. virtual Unix filesystem) which ultimately
ends up causing problems.

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