[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is
a shell script
ivan at theory.asu.ru
Sat Mar 1 14:03:38 EST 2008
>>>>> Hamish <hamish_b at yahoo.com> writes:
>>> bashisms common in GRASS
>> As Bash becomes somewhat less popular in the GNU world and being
>> replaced by other POSIX-compatible Shells, it makes sense to get rid
>> of bashisms irrespective of the platform.
> FWIW all known bashisms were removed prior to GRASS 6.2.2. This is
> mostly because Ubuntu now uses dash for /bin/sh and a lot of folks
> use Ubuntu. Anything left needing bash explicitly uses #!/bin/bash
I. e., `i.spectral', `r.mapcalculator', `r.tileset' and
`v.in.gps.babel'? Could someone please point me to the list of
the identified Shell portability issues of these scripts?
> Michael has a point in that GRASS heavily relies on UNIX shell
> scripts, which is ok for Mac (after fixing GNUisms) but not for MS
> Windows. Msys, mingw, and cygwin exist but are in the end all just
> different ways of putting lipstick on a pig.
>> Well, I've heard of Python, but don't know it.
> for some things it will be easier, for others not. e.g. for shell
> command scripting nothing will ever be as good as sh,
Well, for the Lisp family of the languages a syntax extension
mechanism is an inherent feature. Thus, nothing really prevents
a Lisp from deciphering something like the following:
(| (run "g.mlist" "type=rast" "pattern=2008-\\*-temperature")
(let ((s (concat r "-celsius")))
(run "r.mapcalc" "\"$s\" = \"$r\" - 273.15")))))
Though even such a notation, resembling the Shell code rather
closely, is hardly acceptable for an interactive use. (Except
for ones using Emacs as their command line editor.)
> but for more complex programming python will be better. It's just a
> matter of choosing a compromise. e.g. for your g.mlist example sh is
> hard to beat.
But that's exactly my point -- Python is hardly an alternative
for the 1.5-liners that you type into the Shell interactively.
And depriving a GRASS user of a Shell does, in my opinion,
seriously limit the usefulness of GRASS.
Thus, while MSYS' or Cygwin's Shell (and the ``usual'' tools)
may be somewhat difficult to deploy on W32, it seems to me just
unavoidable to have them installed in order to do anything
useful with GRASS.
As an alternative, it may be that GRASS could benefit from a
Shell (et al)... implemented in Python. It's all but an
original idea. E. g., Emacs implements Eshell , though it
may be noted that because of Emacs Lisp Emacs dependency on the
Shell is much looser than that of GRASS.
Besides, such a Shell would have a much wider field of
applicability than just being the interactive shell for GRASS.
I guess, that may make such a project to attract some interest
from the general Python community.
> But for something complex like r.in.wms or v.in.garmin, sh just isn't
> the right tool for the job.
> for a quick primer see: 10 minutes Python tutorial for programmers of
> other languages http://www.poromenos.org/tutorials/python
More information about the grass-dev