Ivan Shmakov wrote:
> >> It may be a stupid question, but what scripting language is proposed
> >> to replace POSIX Shell in GRASS?
>
> > Python.
>
> ACK, thanks.
>
> >> 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)
>
> Since I don't know Python, could you please show me the script
> like the above rewritten in it?
mlist = Popen(["g.mlist", "type=rast", "pattern=2008-*-temperature"],
stdout=PIPE)
for line in mlist.stdout:
map = line.rstrip()
call(["r.mapcalc", "\"%s-celsius\" = \"%s\" - 273.15" % (map,
map)])
mlist.stdout.close()
> > 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
>
> I wonder, how the script above could be rewritten for cmd.exe?
I wouldn't suggest using cmd.exe for scripts. If you want portability,
use e.g. Python; if you don't, VB would probably be preferable to
cmd.exe.
> > (with bash for people who prefer Unix but have to use Windows).
>
> > But Unix shells suck as programming languages.
>
> Well, perhaps. But its orientation towards calling external
> programs (and the GRASS modules are to be external in the
> foreseeable future?) is a property which the majority of the
> programming languages (at least of the set I know) don't posess.
This is an advantage for interactive usage. For scripts, having to
explicitly type exec/spawn/popen/etc really isn't an issue. If
actually typing the script takes most of the time, you aren't spending
enough time thinking about what you're typing.
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
