>>>>> Markus Neteler <[EMAIL PROTECTED]> writes:
[...]
>> Take a look at the minor change for lib/insert_raster.sh as well
>> (attached.)
> Looks much more polished. But it looks like bash to me, right? So
> far we try to avoid bash-isms in GRASS for portability. Or will it
> run with ash, too?
It seems that both `local' and `$(COMMAND)' are available in
either `dash' or BusyBox' `ash', e. g.:
$ cat test.sh
a=
f () { local a="$1" ; echo "$a" ; }
f "$(echo Hello, world\!)"
echo "\"$a\" is expected to be an empty string"
$ dash test.sh
Hello, world!
"" is expected to be an empty string
$ ash test.sh
Hello, world!
"" is expected to be an empty string
$
It's probably reasonable to require a Shell implementation with
either once you're depending on Shell functions being available.
I'm not sure that these constructs are mandated by any standard,
though.
The `test' (`[ ... ]') command should be generally available as
well. IIRC, it's mandated by POSIX.
[...]
>> In particular, I believe that the generic arrays storage facility is
>> needed in GRASS for a long time. At the very least, the ability to
>> access arbitrary arrays in `r.mapcalc' expressions sounds quite
>> appealing to me.
>> Implementing this facility would effectively split the raster data
>> set implementation into the generic ``raster'' (or ``array'') part
>> and the specific ``geospatial'', ``color mapping'', and ``who knows
>> what'' ones.
> I do agree that the raster part needs a radical renovation. Some team
> members also have ideas here - hope it comes true for GRASS 7.
Are these collected anywhere on the Web (besides of [1, 2])?
[1] http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection
[2] http://grass.gdf-hannover.de/wiki/Replacement_raster_format
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
