[GRASS5] [bug #3177] (grass) g.gisenv

this bug's URL: http://intevation.de/rt/webrt?serial_num=3177
-------------------------------------------------------------------------

  $ g.gisenv help

  Description:
   Outputs the user's current GRASS variable settings.
Sets them also too, no?

  Usage:
   g.gisenv [get=VARIABLE] [set="VARIABLE=value"] [store=name]

  Parameters:
      get GRASS variable to get
      set GRASS variable to set
Why do you say "set" twice?
    store Where GRASS variable is stored
            options: gisrc,mapset
            default: gisrc
Also man g.gisenv doesn't mention GRASS_GUI. One wants to know all the
possible choices. Also mention GRASS_DB_ENCODING, etc.

The man page says
       To disable debugging messages, DEBUG must be set back to 0:
       g.gisenv set="DEBUG=0"
Well for me, I got lots of
  D5/15: Get_location_with_pointer2(): cmd = 2
on the screen still, g.gisenv will not fix things until the user
restarts grass. So say so.

Maybe if the poor choice to race the CPU at 100% when waiting for
mouse input for all grass programs had not been made, the D5/15
message flood wouldn't be so devastating.

--- Headers Follow ---

From jidanni@jidanni.org Sat Apr 23 00:21:13 2005

Return-Path: <jidanni@jidanni.org>
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
  by lists.intevation.de (Postfix) with ESMTP id 5D7631005D7
  for <grass-bugs@lists.intevation.de>; Sat, 23 Apr 2005 00:21:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
  by mail.intevation.de (Postfix) with ESMTP id CD65036CDC
  for <grass-bugs@lists.intevation.de>; Sat, 23 Apr 2005 00:21:12 +0200 (CEST)
Received: from frodo.hserus.net (frodo.hserus.net [204.74.68.40])
  by mail.intevation.de (Postfix) with ESMTP id 384FA36CDB
  for <grass-bugs@intevation.de>; Sat, 23 Apr 2005 00:21:11 +0200 (CEST)
Received: from tc218-187-81-241.2-7.dynamic.apol.com.tw ([218.187.81.241]:33067 helo=jidanni1)
  by frodo.hserus.net with esmtpsa
  (Cipher TLSv1:AES256-SHA:256) (Exim 4.50 #1)
  id 1DP6WF-0005vh-TJ by authid <jidanni> with plain
  for <grass-bugs@intevation.de>; Sat, 23 Apr 2005 03:51:07 +0530
To: grass-bugs@intevation.de
Subject: g.gisenv
From: Dan Jacobson <jidanni@jidanni.org>
Date: Sat, 23 Apr 2005 04:54:22 +0800
Message-ID: <87ekd2h6rl.fsf@jidanni.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level:

-------------------------------------------- Managed by Request Tracker

On Sat, Apr 23, 2005 at 12:21:13AM +0200, Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=3177
-------------------------------------------------------------------------

  $ g.gisenv help

  Description:
   Outputs the user's current GRASS variable settings.
Sets them also too, no?

Fixed in both 6.1-CVS and 6.0.1-CVS/release branch.

  Usage:
   g.gisenv [get=VARIABLE] [set="VARIABLE=value"] [store=name]

  Parameters:
      get GRASS variable to get
      set GRASS variable to set
Why do you say "set" twice?

why not?

    store Where GRASS variable is stored
            options: gisrc,mapset
            default: gisrc
Also man g.gisenv doesn't mention GRASS_GUI. One wants to know all the
possible choices. Also mention GRASS_DB_ENCODING, etc.

RTFM:
http://grass.itc.it/grass60/manuals/html60_user/g.gisenv.html
"Possible variable names depend on the user's system, see variables list for details."
-> http://grass.itc.it/grass60/manuals/html60_user/variables.html

The man page says
       To disable debugging messages, DEBUG must be set back to 0:
       g.gisenv set="DEBUG=0"
Well for me, I got lots of
  D5/15: Get_location_with_pointer2(): cmd = 2
on the screen still, g.gisenv will not fix things until the user
restarts grass. So say so.

You are using an outdated version of GRASS.

Maybe if the poor choice to race the CPU at 100% when waiting for
mouse input for all grass programs had not been made, the D5/15
message flood wouldn't be so devastating.

The CPU/d.* issue was already discussed a couple of times.

Markus