[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