[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is a shell script

[Glynn Clements]

Ivan Shmakov wrote:

>  > 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?

Python.

>  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)

Interactive command-line use will continue to be through whichever
shell the user prefers, typically bash on Unix (maybe with the odd csh
user) and cmd.exe on Windows (with bash for people who prefer Unix but
have to use Windows).

But Unix shells suck as programming languages. The only reason to use
Bourne shell for scripts is the fact that an interpreter is guaranteed
to be present on every Unix system. But as GRASS is no longer limited
to Unix, that's no longer an advantage.

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