[GRASS-dev] GUI platforms

[Glynn Clements]

David Finlayson wrote:

> The problem is not the particular shell used (though there are
> advantages to establishing a standard), it is the missing toolbox on
> Windows. Windows out-of-the-box doesn't provide the tools to do
> anything useful. Everything needs to be provided. There are several
> options:
> 
> 1. You can supply a Unix emulation layer and bash as Cygwin does
> (there are others) and all scripts run cross-platform across the three
> architectures. This is what is being done today.
> 
> 2. You supply a tool set and allow Windows to use a native shell (cmd
> or whatever). I think in this case the obvious easy path is to supply
> the tools already available on Unix systems, but recreating a new tool
> set isn't inconceivable. Care needs to be taken to make this all work
> cross-platform without crippling one system or the other. I can't
> imagine that true cross-platform scripting can be achieved this way
> without essentially duplicating what Cygwin already provides.

bash, along with most of the common text-processing tools are
available in versions which don't require Cygwin. They've been
available in the MKS toolkit for decades, and there's also the
GNU-Win32 project.

That kind of program really doesn't need accurate Unix compatibility;
you just need to be able to read and write files. The level of
compatibility which Cygwin provides just creates complications (and
also incurs a massive performance penalty).

> 3. You code to the lowest common denominator making no assumptions
> about a Unix toolbox or a scripting environment. Here is where you
> will probably need to supply grass with its own "shell". Maybe a
> Python interpreter with an object model for communication with GRASS
> (like ArcGIS has done).

This is up to the user. If I was developing an in-house tool based
upon GRASS, I wouldn't use bash for any non-trivial scripts. If you're
planning on distributing the software, you need to consider the target
audience. If your target audience lives and breathes Windows, bash
would be the wrong choice; you would be better of with cmd.exe batch
files, in spite of cmd.exe being the only language in existence which
is objectively worse than bash as a programming language.

There's still the issue of which language to use for any scripts
included as part of GRASS. While we currently use Bourne shell (well,
there are probably a few bash-isms in some of the scripts, but we
usually fix those if someone points them out), you could make a
reasonable argument for using Perl instead. On Unix, it's almost as
commonplace as /bin/sh nowadays; on Windows, it's probably more
common. Regardless of platform, it has to be a better language than
bash (FWIW, I don't like Perl; but then I'm not particularly fond of
using bash for anything longer than 10 lines either).

> IMHO, option 3 ends GRASS as a real Unix program.
> 
> Part of the issue is that 99% of tools designed for native use on
> Windows (and GUI Mac) are not programmed to use text streams. The only
> way to communicate with them is through remote procedure calls. That
> is why Windows provides the Windows Scripting Host (WSH). Python and
> Perl use COM, etc. GRASS's shell will need to support this world view.

That isn't going to happen. If GRASS ditched bash in favour of Perl or
Python for its standard scripting language, the scripting interface
would still be through spawning commands, redirecting/piping
stdin/stdout, reading/writing files etc.

Switching to COM/CORBA/OLE/RPC/etc wouldn't be an issue of GRASS no
longer being a Unix program, but an issue of it no longer being GRASS. 
It would require a complete top-to-bottom rewrite, and that isn't
going to happen.

> If you've done much scripting in Windows using native tools, you'll
> find it is a very different monster than on Unix. Your code becomes
> boiler plate procedure calls to the scripting host and you work with
> the back-end API of things like MS Office applications. One line of
> bash with a few pipes turns into dozens of lines of object-oriented
> goop, even in Python.
> 
> Certainly, if we are going down that route I would rather see it in
> Python than almost any other scripting language. But I think this
> approach has long-term implications for the GRASS architecture that go
> well beyond the GUI issues we are dealing with today.

We aren't going down that route.

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