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

[Ivan Shmakov]

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

(like-a-shell
  (| (run "g.mlist" "type=rast" "pattern=2008-\\*-temperature")
     (for-each-line r
       (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 [1], 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

[1] http://www.gnu.org/software/emacs/manual/html_mono/eshell.html