Hi
for some time the $LOCATION variable is gone now and must
be constructed with 'g.gisenv'. As far as I know the underlying
idea was to allow for GRASS parallel sessions.
Since that feature is not (yet) functional, should we re-enable
the $LOCATION (e.g. in ETC/Init.sh) until GRASS parallel sessions
become possible? $LOCATION is pretty often used and quite
convenient over constructing (more or less) on the fly with g.gisenv.
Markus
On Wed, May 15, 2002 at 03:22:17PM +0200, Markus Neteler wrote:
for some time the $LOCATION variable is gone now and must
be constructed with 'g.gisenv'. As far as I know the underlying
idea was to allow for GRASS parallel sessions.Since that feature is not (yet) functional, should we re-enable
the $LOCATION (e.g. in ETC/Init.sh) until GRASS parallel sessions
become possible? $LOCATION is pretty often used and quite
convenient over constructing (more or less) on the fly with g.gisenv.
AFAIU this change was good for the future and consistancy reasons anyway.
So why not keep it as it is in there already?
It will start migration earler.
Markus Neteler wrote:
for some time the $LOCATION variable is gone now and must
be constructed with 'g.gisenv'. As far as I know the underlying
idea was to allow for GRASS parallel sessions.
The motivation was to allow changing the location/mapset within a
session.
Since that feature is not (yet) functional,
AFAICT, it is functional:
g.gisenv set=LOCATION_NAME=spearfish
d.rast elevation.dem
g.gisenv set=LOCATION_NAME=global
d.rast nations
Except that anything which uses the monitor's "list" pad (auto-redraw,
d.save, d.redraw etc) won't work. But that's a fundamental design
flaw, with no simple fix.
Note that the above example would have worked before the settings were
removed from Init.sh. However, anything which used the environment
variables (e.g. tcltkgrass, nviz, and most scripts) would continue to
use the settings with which the session was started.
Reflecting $GISRC into the environment was a partial work-around for
broken programs. The simplest way to find the bugs is to remove the
work-around.
should we re-enable
the $LOCATION (e.g. in ETC/Init.sh) until GRASS parallel sessions
become possible? $LOCATION is pretty often used and quite
convenient over constructing (more or less) on the fly with g.gisenv.
No.
If users want to set LOCATION for their own use, they can do it in
~/.grass.bashrc. If it's set in Init.sh, there's a danger that it
might get used by programs or scripts.
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
Markus Neteler wrote:
> for some time the $LOCATION variable is gone now and must
> be constructed with 'g.gisenv'. As far as I know the underlying
> idea was to allow for GRASS parallel sessions.The motivation was to allow changing the location/mapset within a
session.
This is a pretty big (and welcome) change which is not explained anywhere
and not really tested, so I would very much encourage everybody to run
their
scripts and programs to see what kind of problems it may (or hopefully
will not) create.
> Since that feature is not (yet) functional,
AFAICT, it is functional:
g.gisenv set=LOCATION_NAME=spearfish
d.rast elevation.dem
g.gisenv set=LOCATION_NAME=global
d.rast nationsExcept that anything which uses the monitor's "list" pad (auto-redraw,
d.save, d.redraw etc) won't work. But that's a fundamental design
flaw, with no simple fix.Note that the above example would have worked before the settings were
removed from Init.sh. However, anything which used the environment
variables (e.g. tcltkgrass, nviz, and most scripts) would continue to
use the settings with which the session was started.
this is really confusing and if we want to keep the change it needs to be
clearly
explained at a prominent place when downloading the new release. Do I
understand
it correctly that in the previous example if I do
nviz nations
the map won't be there because nviz would still use the original LOCATION?
Do the current scripts released with GRASS which use $LOCATION work
correctly? -
or what is the correct behavior - as I understand it they would use the
original LOCATION
and not the one set by g.gisenv?
Or am I completely missing something here?
Helena
Reflecting $GISRC into the environment was a partial work-around for
broken programs. The simplest way to find the bugs is to remove the
work-around.> should we re-enable
> the $LOCATION (e.g. in ETC/Init.sh) until GRASS parallel sessions
> become possible? $LOCATION is pretty often used and quite
> convenient over constructing (more or less) on the fly with g.gisenv.No.
If users want to set LOCATION for their own use, they can do it in
~/.grass.bashrc. If it's set in Init.sh, there's a danger that it
might get used by programs or scripts.--
Glynn Clements <glynn.clements@virgin.net>
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
Helena wrote:
> Note that the above example would have worked before the settings were
> removed from Init.sh. However, anything which used the environment
> variables (e.g. tcltkgrass, nviz, and most scripts) would continue to
> use the settings with which the session was started.this is really confusing and if we want to keep the change it needs to be
clearly
explained at a prominent place when downloading the new release. Do I
understand
it correctly that in the previous example if I donviz nations
the map won't be there because nviz would still use the original LOCATION?
Do the current scripts released with GRASS which use $LOCATION work
correctly? -
or what is the correct behavior - as I understand it they would use the
original LOCATION
and not the one set by g.gisenv?
Or am I completely missing something here?
Anything which was found to be dependent upon the environment
variables was fixed. AFAIK, this includes everything in src/scripts,
plus tcltkgrass and nviz.
However, I can't absolutely rule out the possibility that something
may have slipped through the net. Now that you mention it, I recall
Markus mentioning a Perl script which needed fixing; I don't recall
the outcome, though.
--
Glynn Clements <glynn.clements@virgin.net>
i responded to this thread hours ago, but it didn't make it onto the list.
I'm not sure why $LOCATION would cause problems for multiple sessions in
GRASS. I can see a problem if multiple sessions are implemented as
simultaneous threads (which would be difficult at best). If instead multiple
sessions are implemented so that the user switches from session to session
and only one session is actually running at one time then it is only
necessary to change the definition of $LOCATION when the user switches
sessions.
I have been using multiple sessions with my manager module. Each session has
its own monitor, window region and gis environment. When the user changes
from one session to another the monitor, window region and gis environment
are all changed by the manager. The command that switches sessions also
makes it possible to change $LOCATION.
That works well in the bash shell. Other user environments might be more
problematic. Also, I don't think I use any of the scripts (nviz in
particular) that depend on $LOCATION, so in my case having $LOCATION is just
a convenience for the command line and/or user scripts.
Roger Miller
On Wed, May 15, 2002 at 10:28:31PM +0100, Glynn Clements wrote:
Helena wrote:
> > Note that the above example would have worked before the settings were
> > removed from Init.sh. However, anything which used the environment
> > variables (e.g. tcltkgrass, nviz, and most scripts) would continue to
> > use the settings with which the session was started.
>
> this is really confusing and if we want to keep the change it needs to be
> clearly
> explained at a prominent place when downloading the new release. Do I
> understand
> it correctly that in the previous example if I do
>
> nviz nations
>
> the map won't be there because nviz would still use the original LOCATION?
>
> Do the current scripts released with GRASS which use $LOCATION work
> correctly? -
> or what is the correct behavior - as I understand it they would use the
> original LOCATION
> and not the one set by g.gisenv?
> Or am I completely missing something here?Anything which was found to be dependent upon the environment
variables was fixed. AFAIK, this includes everything in src/scripts,
plus tcltkgrass and nviz.However, I can't absolutely rule out the possibility that something
may have slipped through the net. Now that you mention it, I recall
Markus mentioning a Perl script which needed fixing; I don't recall
the outcome, though.
We had problems with our *local* scripts (30 or more). Eventually
a PERL script in GRASS also needs a fix.
Our workaround for PERL was to
#read the GRASS variables:
open(RRR,"g.gisenv |");
while(<RRR>){
chop();
chop();
@part=split(/=/,$_);
$part[1]=~s/\'//g;
$ENV{"$part[0]"}="$part[1]";
}
close RRR;
$ENV{LOCATION}="$ENV{GISDBASE}/$ENV{LOCATION_NAME}/$ENV{MAPSET}";
which looks pretty complicated compared to Shell scripts.
Is there a more elegant solution to get the environment into
PERL (I am no PERL users).
Also Helena was refering to her local scripts. We have to teach
people how to upgrade.
Markus
Markus Neteler wrote:
> However, I can't absolutely rule out the possibility that something
> may have slipped through the net. Now that you mention it, I recall
> Markus mentioning a Perl script which needed fixing; I don't recall
> the outcome, though.We had problems with our *local* scripts (30 or more). Eventually
a PERL script in GRASS also needs a fix.Our workaround for PERL was to
#read the GRASS variables:
open(RRR,"g.gisenv |");
while(<RRR>){
chop();
chop();
@part=split(/=/,$_);
$part[1]=~s/\'//g;
$ENV{"$part[0]"}="$part[1]";
}
close RRR;
$ENV{LOCATION}="$ENV{GISDBASE}/$ENV{LOCATION_NAME}/$ENV{MAPSET}";which looks pretty complicated compared to Shell scripts.
Is there a more elegant solution to get the environment into
PERL (I am no PERL users).
Like Bourne shell, Perl has backticks. But, unlike Bourne shell,
Perl's backticks don't strip the newline from the output. So, using:
$gisdbase=`g.gisenv get=GISDBASE`
includes the trailing newline. If you can figure out how to remove it,
that may be simpler than the loop.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, May 16, 2002 at 09:51:14AM +0100, Glynn Clements wrote:
Like Bourne shell, Perl has backticks. But, unlike Bourne shell,
Perl's backticks don't strip the newline from the output. So, using:$gisdbase=`g.gisenv get=GISDBASE`
includes the trailing newline. If you can figure out how to remove it,
that may be simpler than the loop.
Errmm...
$ENV{GISDBASE} = `g.gisenv get=GISDBASE`;
chomp $ENV{GISDBASE};
$ENV{LOCATION_NAME} = `g.gisenv get=LOCATION_NAME`;
chomp $ENV{LOCATION_NAME};
$ENV{MAPSET} = `g.gisenv get=MAPSET`;
chomp $ENV{MAPSET};
$ENV{LOCATION} = "$ENV{GISDBASE}/$ENV{LOCATION_NAME}/$ENV{MAPSET}";
--
Eric G. Miller <egm2@jps.net>
Eric G. Miller wrote:
> Like Bourne shell, Perl has backticks. But, unlike Bourne shell,
> Perl's backticks don't strip the newline from the output. So, using:
>
> $gisdbase=`g.gisenv get=GISDBASE`
>
> includes the trailing newline. If you can figure out how to remove it,
> that may be simpler than the loop.$ENV{GISDBASE} = `g.gisenv get=GISDBASE`;
chomp $ENV{GISDBASE};
$ENV{LOCATION_NAME} = `g.gisenv get=LOCATION_NAME`;
chomp $ENV{LOCATION_NAME};
$ENV{MAPSET} = `g.gisenv get=MAPSET`;
chomp $ENV{MAPSET};
$ENV{LOCATION} = "$ENV{GISDBASE}/$ENV{LOCATION_NAME}/$ENV{MAPSET}";
Normally, it's preferable to use "normal" variables rather than
environment variables, as environment space is a limited resource (and
shared with the argument list, so consuming environment space reduces
the maximum length of an argument list).
Environment variables should only be used if you need to update an
existing script which already refers to environment variables. They
shouldn't be used for new scripts.
--
Glynn Clements <glynn.clements@virgin.net>
On Thu, May 16, 2002 at 12:17:09PM +0100, Glynn Clements wrote:
Normally, it's preferable to use "normal" variables rather than
environment variables, as environment space is a limited resource (and
shared with the argument list, so consuming environment space reduces
the maximum length of an argument list).
I don't think adding environment variables in a perl script runs into
those same limitations unless the script spawns children. 'Course, if
the script doesn't spawn any children, there's probably no reason to
use the %ENV hash to begin with (unless you're lazy and want a special
global hash).
Anyway, the point was to use "chomp" to remove newlines, not anything
about the variables. I just use %ENV as an example, as that was what
Markus' script was doing...
Maybe the script below is a better example? Only one g.gisenv call.
#! /usr/bin/perl -w
local %gisenv;
my $input = `g.gisenv`;
my @arr = split /\n/, $input;
foreach $item (@arr) {
my ($k,$v) = split /=/, $item;
$v =~ s/\'//gc;
$gisenv{$k} = $v;
print "\$gisenv{$k} = $gisenv{$k}\n";
}
--
Eric G. Miller <egm2@jps.net>
Markus,
Are the changes to the environment variables documented anywhere? Sorry
of this question has already been asked and answered a while ago.
The reason I am asking is related to NVIZ. I have just finished
modifying ogsf to accept fully qualifid raster names (rasters from other
mapsets -- eg. nviz e=raster@mapset2). Hopefully this is not redundant.
My next step is to modify the TCL stuff to pickup and pass on fully
qualified names.
Any help would be appreciated.
--
Bob Covill
Tekmap Consulting
P.O. Box 2016 Fall River, N.S.
B2T 1K6
Canada
E-Mail: bcovill@tekmap.ns.ca
Bob Covill wrote:
Are the changes to the environment variables documented anywhere?
No. OTOH, the original semantics weren't documented anywhere either.
Most of the documentation regarding these settings which I have seen
is incorrect. It usually refers to "environment" variables, even
though anything which is written in C uses G_getenv(), which has
nothing to do with the environment. It's arguable that the function
should be renamed; people are bound to assume that, like getenv(), it
has something to do with the environment.
The reason I am asking is related to NVIZ. I have just finished
modifying ogsf to accept fully qualifid raster names (rasters from other
mapsets -- eg. nviz e=raster@mapset2). Hopefully this is not redundant.
My next step is to modify the TCL stuff to pickup and pass on fully
qualified names.
It shouldn't affect NVIZ. The NVIZ startup script ($GISBASE/bin/nviz)
was changed to reflect GISDBASE, LOCATION_NAME and MAPSET into the
environment prior to actually invoking NVWISH2.2.
So, the only impact should be that the values of $MAPSET etc will be
those which were in effect at the time that "nviz" was run, rather
than at the time the GRASS session was started.
Ideally, NVIZ should be G_getenv() for these settings ("nm" indicates
that it's already using G_getenv() for something).
--
Glynn Clements <glynn.clements@virgin.net>