Details Ticket 1797


Comment | Reply | Take | Open


Serial Number 1797
Subject g.gisenv
Area wish
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status resolved
Last User Contact Wed Jun 25 04:49:28 2003 (5 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Fri Oct 22 07:15:40 2004 (4 yr ago)
Created Sat Apr 12 09:33:39 2003 (5 yr ago)

Transaction History Ticket 1797


Sat, Apr 12 2003 09:33:39    Request created by hbowman  
Subject: g.gisenv

g.gisenv lets you set a variable to nonexistant values without a check, and
the only way to go on is to exit GRASS and delete/edit the .grassrc5 file.

e.g., (user1 exists, usr1 doesn't)

GRASS:~ > g.gisenv MAPSET
user1
GRASS:~ > g.gisenv set="MAPSET=usr1"
GRASS:~ >
GRASS:~ > g.gisenv
ERROR: MAPSET usr1 not found
GRASS:~ >
GRASS:~ > g.gisenv set="MAPSET=user1"
ERROR: MAPSET usr1 not found
GRASS:~ > exit


I had a try using G_getenv to make a backup copy of the old value before
attempting to G_setenv, and then test G_getenv for success, but as G_getenv
fails with an exit, I can't set it back to the original if it fails..

When you try to fix it later with another set= to a real value, it fails (and
G_fatal_error's) again before it can set the new value.

any ideas?


Hamish
Sat, Apr 12 2003 12:15:26    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16023.58194.195758.816614@cerise.nosuchdomain.co.uk>
Date Sat, 12 Apr 2003 10:58:42 +0100
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1797] (grass) g.gisenv
In-Reply-To <20030412073339.D420313B0F@lists.intevation.de>
References <20030412073339.D420313B0F@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Status No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.44
X-Spam-Level
Request Tracker wrote:

> Subject: g.gisenv
> 
> g.gisenv lets you set a variable to nonexistant values without a check, and
> the only way to go on is to exit GRASS and delete/edit the .grassrc5 file.
> 
> e.g., (user1 exists, usr1 doesn't)
> 
> GRASS:~ > g.gisenv MAPSET
> user1
> GRASS:~ > g.gisenv set="MAPSET=usr1"
> GRASS:~ >
> GRASS:~ > g.gisenv
> ERROR: MAPSET usr1 not found
> GRASS:~ >
> GRASS:~ > g.gisenv set="MAPSET=user1"
> ERROR: MAPSET usr1 not found
> GRASS:~ > exit
> 
> 
> I had a try using G_getenv to make a backup copy of the old value before
> attempting to G_setenv, and then test G_getenv for success, but as G_getenv
> fails with an exit, I can't set it back to the original if it fails..
> 
> When you try to fix it later with another set= to a real value, it fails (and
> G_fatal_error's) again before it can set the new value.
> 
> any ideas?

g.gisenv calls G_gisinit(), which generates a fatal error if the
mapset directory doesn't exist or has incorrect permissions (i.e. 
ownership).

Using:

	G_set_program_name(argv[0]);
	G_no_gisinit();

should work.

-- 
Glynn Clements <glynn.clements@virgin.net>


Thu, Apr 17 2003 05:46:16    Mail sent by hbowman  
Thu, Apr 17 2003 06:18:20    Mail sent by hbowman  
sorry about that last empty message, pressed enter in the wrong place.


With respect to being able to set a new mapset after the old has been set
incorrectly with g.gisenv, this seems to work fine, thanks. Can you forsee any
unwanted repercussions?


--- grass/src/general/g.gisenv/main.c	Sat Apr 12 18:24:38 2003
+++ grass/src/general/g.gisenv/main.c.NEW	Thu Apr 17 15:43:02 2003
@@ -12,7 +12,8 @@
     struct Option *get, *set;
     struct GModule *module;
     
-    G_gisinit (argv[0]);
+    G_set_program_name(argv[0]);
+    G_no_gisinit();
 
     module = G_define_module();
     module->description =


I'm still looking for a (gis lib) way of testing to see if a mapset/whatever
exists without the library function generating a fatal error. ?
(for test before G_setenv)


> > Subject: g.gisenv
> > 
> > g.gisenv lets you set a variable to nonexistant values without a check,
> > and the only way to go on is to exit GRASS and delete/edit the .grassrc5
> > file.
> > 
> > any ideas?
> 
> g.gisenv calls G_gisinit(), which generates a fatal error if the
> mapset directory doesn't exist or has incorrect permissions (i.e. 
> ownership).
> 
> Using:
> 
> 	G_set_program_name(argv[0]);
> 	G_no_gisinit();
> 
> should work.
Fri, Apr 18 2003 02:27:59    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16031.12581.124890.86854@cerise.nosuchdomain.co.uk>
Date Thu, 17 Apr 2003 23:56:37 +0100
To Harmisch Bowman via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1797] (grass) g.gisenv
In-Reply-To <20030417041821.4A80913B51@lists.intevation.de>
References <20030417041821.4A80913B51@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Status No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.44
X-Spam-Level
Harmisch Bowman via RT wrote:

> With respect to being able to set a new mapset after the old has been set
> incorrectly with g.gisenv, this seems to work fine, thanks. Can you forsee
any
> unwanted repercussions?

No. The only code which is actually bypassed by that change is the
check for a valid database/location/mapset. I've looked through the
various parts of libgis which could be called (basically parser.c and
env.c), and I can't see any way in which this could matter.

> I'm still looking for a (gis lib) way of testing to see if a mapset/whatever
> exists without the library function generating a fatal error. ?
> (for test before G_setenv)

G__mapset_permissions() should do the job. The database and location
parameters need to be set; the mapset is passed as a parameter.

I wouldn't recommend adding special-case checks to g.gisenv. However,
it would be useful to have a better way to change the GISDBASE,
LOCATION_NAME and MAPSET parameters. Either a dedicated utility, or a
re-write of the set_data program.

BTW, a few things still don't like database/location/mapset switching;
primarily tcltkgrass (this needs to call g.gisenv for each operation,
rather than just at the start of the program) and XDRIVER's resize
handling (which should just be removed).

-- 
Glynn Clements <glynn.clements@virgin.net>


Fri, Apr 18 2003 04:26:56    Mail sent by hbowman  
>> With respect to being able to set a new mapset after the old has been set
>> incorrectly with g.gisenv, this seems to work fine, thanks. Can you foresee
>> any unwanted repercussions?
>
> No.

Right then, I've committed that change to CVS.



>> I'm still looking for a (gis lib) way of testing to see if a
>> mapset/whatever exists without the library function generating a fatal
>> error. ? (for test before G_setenv)
>
> G__mapset_permissions() should do the job. The database and location
> parameters need to be set; the mapset is passed as a parameter.

I'll give it a try.


> I wouldn't recommend adding special-case checks to g.gisenv. However,
> it would be useful to have a better way to change the GISDBASE,
> LOCATION_NAME and MAPSET parameters. Either a dedicated utility, or a
> re-write of the set_data program.

Simply calling G_getenv after G_setenv will at least tell you you've done
something wrong, at least for the mapset & location, even if it leaves it in
a
broken state.

I've thought that g.gisenv might better mimic the command line, e.g.:
$> g.gisenv MAPSET
oldmapset
$> g.gisenv MAPSET=newmapset
$> 
$> g.gisenv UNUSED=   # unset a variable
$>

and doing away with the get= and set= altogether. shrug.


> BTW, a few things still don't like database/location/mapset switching;
> primarily tcltkgrass (this needs to call g.gisenv for each operation,
> rather than just at the start of the program) and XDRIVER's resize
> handling (which should just be removed).


Yes, I suppose prominent notes about this in the man page and not widely
advertizing the set= feature until it works 100% with everything is the way to
go..


Hamish
Fri, Apr 18 2003 19:00:34    Mail sent by glynn.clements@virgin.net  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn.clements@virgin.net>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16032.9165.630239.309903@cerise.nosuchdomain.co.uk>
Date Fri, 18 Apr 2003 17:11:57 +0100
To Harmisch Bowman via RT <grass-bugs@intevation.de>
Subject Re: [bug #1797] (grass) g.gisenv
In-Reply-To <20030418022656.1EBBA139C5@lists.intevation.de>
References <20030418022656.1EBBA139C5@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid
X-Spam-Status No, hits=-3.2 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01 version=2.44
X-Spam-Level
Harmisch Bowman via RT wrote:

> > I wouldn't recommend adding special-case checks to g.gisenv. However,
> > it would be useful to have a better way to change the GISDBASE,
> > LOCATION_NAME and MAPSET parameters. Either a dedicated utility, or a
> > re-write of the set_data program.
> 
> Simply calling G_getenv after G_setenv will at least tell you you've done
> something wrong, at least for the mapset & location, even if it leaves it in
a
> broken state.

Note that G__setenv() (two underscores) will update the program's copy
of the environment without modifying the $GISRC file. The obvious
approach would be to use G__setenv(), check for breakage, then use
G__write_env() if everything looks OK.

-- 
Glynn Clements <glynn.clements@virgin.net>


Mon, May 12 2003 11:09:12    Mail sent by hbowman  
> I wouldn't recommend adding special-case checks to g.gisenv. However,
> it would be useful to have a better way to change the GISDBASE,
> LOCATION_NAME and MAPSET parameters. Either a dedicated utility, or a
> re-write of the set_data program.

ok, that in mind I won't put this into CVS, but the following makes my day easier.
(mind the bugtracker input window linewrap)


--- src/general/g.gisenv/main.c.CVS	Thu Apr 17 15:43:02 2003
+++ src/general/g.gisenv/main.c	Mon May 12 20:53:03 2003
@@ -8,7 +8,7 @@
 {
     int n;
     int tty;
-    char *name, *value, *ptr;
+    char *name, *value, *ptr, *old_value;
     struct Option *get, *set;
     struct GModule *module;
     
@@ -74,12 +74,30 @@
 	/* Allow unset without '=' sign */
 	if (value != NULL && *value == '\0')
 	  value = NULL ;
-
  
-        G_setenv (name, value) ;
+
+
old_value = G__getenv(name);
+
+
G_setenv(name, value);
+
+
/* we test after setting to be able to recover from a bad set */
+
+
if (!strcmp ("MAPSET", name)) {
+
    switch (G__mapset_permissions (value)) {
+
	case 1:
+
	    break;
+
	case 0:
+
	    G_warning("MAPSET \"%s\" belongs to another user: Read Only", value);
+
	    break;
+
	default:
+
	    G_setenv(name, old_value);
+
	    G_fatal_error ("MAPSET \"%s\" not found", value);
+
	    break;
+
    }
+
}
 
 	return 0;
     }
-

+
     /* Something's wrong if we got this far */
     G_usage();
     return -1;
Tue, Jun 24 2003 17:19:07    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 24 Jun 2003 17:19:04 +0200
From Markus Neteler <neteler@itc.it>
To Harmisch Bowman via RT <grass-bugs@intevation.de>
Subject Re: [GRASS5] [bug #1797] (grass) g.gisenv
Message-ID <20030624171904.Q3882@itc.it>
References <20030417041821.4A80913B51@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5.1i
In-Reply-To <20030417041821.4A80913B51@lists.intevation.de>; from grass-bugs@intevation.de on Thu, Apr 17, 2003 at 06:18:21AM +0200
X-Spam-Status No, hits=-2.2 required=5.0 tests=IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT, USER_AGENT_MUTT version=2.44
X-Spam-Level
Hi Hamish,

should this be still added to 5.1?

Markus


Wed, Jun 25 2003 04:49:28    Mail sent by hbowman  
> should this be still added to 5.1?


I just added the recovery fix that is in 5.0, but not the mapset existence
checking patch in the bug-log.

I still haven't set up 5.1 locally so I haven't tested (in 5.1) what I just
committed.


Hamish
Fri, Oct 22 2004 07:15:40    Status changed to resolved by hbowman  
Fri, Oct 22 2004 07:15:40    Comments added by hbowman  
5.7 has g.mapset (without an "s$") which does mapset checking.

g.gisenv set="MAPSET=foo" 
will remain flexible.


Note g.mapset uses G__mapset_permissions2(), but a directory (without even a
WIND file) will pass the test. Running 'g.region -p' will generate one, d.rast
etc fail with an informative error message, so no big deal.



Hamish
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request