[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as
wxgui is a shell script
Michael Barton
michael.barton at asu.edu
Thu Feb 28 16:26:29 EST 2008
On Feb 28, 2008, at 1:56 PM, grass-dev-request at lists.osgeo.org wrote:
> Date: Fri, 29 Feb 2008 00:04:59 +0600
> From: Ivan Shmakov <ivan at theory.asu.ru>
> Subject: [GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as
> wxgui is a shell script
> To: grass-dev at lists.osgeo.org
> Cc: Ivan Shmakov <oneingray at gmail.com>
> Message-ID: <m2pruhj6t0.fsf at cherry.siamics.int>
> Content-Type: text/plain; charset=us-ascii
>
>>>>>> Michael Barton <michael.barton at asu.edu> writes:
>
> [...]
>
>> I thought the whole reason to have a C-based g.gui was to avoid the
>> use of *nix specific bash shell scripts for launching GUI's. That way
>> they would work on all systems without the hack of having to rewrite
>> *.sh as a *.bat. Why can't the C-code just do the job of the old
>> shell scripts and directly launch the GUI code in TclTk or wxPython.
>
>> The shell scripts are only a convenience anyway, as these could be
>> launched from the GRASS command line with a bit more complicated
>> command--e.g., python "$GISBASE/etc/wxpython/wxgui.py" &
>
>> The name of the initialization module for each GUI (e.g., wxguy.py in
>> wxPython) could be set to a variable in init.sh (or its successor) to
>> avoid hard coding it in C.
>
> It may be a stupid question, but what scripting language is
> proposed to replace POSIX Shell in GRASS? The GRASS environment
> seems to benefit a lot from relying on a Shell-like language.
> E. g., I could hardly imagine using any language other than
> Shell for the following:
>
> $ g.mlist type=rast pattern=2008-\*-temperature \
> (while read r ; do
> s="$r"-celsius ; r.mapcalc "\"$s\" = \"$r\" - 273.15" ; \
> done)
>
> (Surely, there's an Olin Shivers et al work [1, 2], but it seems
> to me that Shell is a bit easier to explain to a non-programmer
> than Scheme [3, 4].)
>
> [1] http://www.scsh.net/
> [2] http://www.scsh.net/resources/commander-s.html
> [3] http://www.r6rs.org/
> [4] http://www.schemers.org/
>
For the foreseeable future, Linux/Unix systems will continue to have a
shell available to do the operation in your example. One of the
important features of GRASS is that many operations can be performed
in a variety of scripting environments--including bash or other shells.
However, Windows does not have a shell. If GRASS is to be truly cross-
platform, then all basic GRASS functions need to operate on all
supported platforms. This poses a significant problem for Windows
users. Cygwin has been quite difficult to install for most users, very
difficult to use in a shared classroom/lab setting, and (in my
experience) somewhat unstable. There is now a 'native' Windows build
of GRASS, but it requires custom hacks for bash scripts and other
bashisms common in GRASS--and installing msys--and these have been the
most problematic part of running GRASS in Windows so far.
Also, many users are not particularly comfortable with arcane bash
shell commands--like in your example above--although I know others who
have a special fondness for bash.
The current plan is ultimately for all core GRASS functions to run as
binaries in a cross-platform compiled language (C for most things) OR
in Python as a cross-platform scripting environment for GUI and
'permanent' scripts (i.e., those that are distributed as part of
GRASS). I'm not familiar with Olin Shivers; I've heard of Scheme, but
don't know it. However, IMHO, Python is much easier to teach someone
and to work with than bash.
Nevertheless, for those on *nix systems, bash will continue to be a
scripting platform for GRASS into the near future.
Michael
More information about the grass-dev
mailing list