Details Ticket 5483


Comment | Reply | Take | Open


Serial Number 5483
Subject g.mremove through gis manager GUI seems not to work well
Area grass6
Queue grass
Requestors aldo.clerici@unipr.it
Owner none
Status resolved
Last User Contact Tue Feb 13 00:37:08 2007 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Tue Feb 13 00:37:53 2007 (2 yr ago)
Created Wed Feb 7 10:59:11 2007 (2 yr ago)

Transaction History Ticket 5483


Wed, Feb 7 2007 10:59:11    Request created by guest  
Subject: g.mremove through gis manager GUI seems not to work well

Platform: GNU/Linux/ppc
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: GRASS6.2/6.3

Aldo Clerici. 
The command File > Manage maps and volumes > Remove maps using expressions and
wildcards require an acknowledgment in the form:

Collecting map names for current mapset <esercizi>....
g.remove rast=geology.new,slope.new
Did you mean this (y/n)?

But it seems not to accept any kind of input (y,yes,n,no). It seems to wait for
something else.

Same behaviour in grass6.2 and 6.3.
The same command g.mremove in command line mode works well.
Wed, Feb 7 2007 11:07:50    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
X-AuditID d94d5003-acf58bb0000004c3-c0-45c9a4f440a8
Message-ID <45C9A4F3.5040304@itc.it>
Date Wed, 07 Feb 2007 11:07:47 +0100
From Markus Neteler <neteler@itc.it>
User-Agent Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version 1.0
To Request Tracker <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
References <20070207095911.CADFA1005C4@lists.intevation.de>
In-Reply-To <20070207095911.CADFA1005C4@lists.intevation.de>
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-OriginalArrivalTime 07 Feb 2007 10:07:47.0677 (UTC) FILETIME=[D166A8D0:01C74A9F]
X-Brightmail-Tracker AAAAAA==
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Request Tracker wrote on 02/07/2007 10:59 AM:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5483
> -------------------------------------------------------------------------
>
> Subject: g.mremove through gis manager GUI seems not to work well
>
> Platform: GNU/Linux/ppc
> grass obtained from: Mirror of Trento site
> grass binary for platform: Compiled from Sources
> GRASS Version: GRASS6.2/6.3
>
> Aldo Clerici. 
> The command File > Manage maps and volumes > Remove maps using expressions
and wildcards require an acknowledgment in the form:
>
> Collecting map names for current mapset <esercizi>....
> g.remove rast=geology.new,slope.new
> Did you mean this (y/n)?
>
> But it seems not to accept any kind of input (y,yes,n,no). It seems to wait
for something else.
>   

Aldo,
up to now interactive input in tcl based dialogs is not possible.
Using the -f flag (force removal) you can delete also in gis.m.

Probably we need to enforce -f somehow in gis.m - how to do that?

Markus

> Same behaviour in grass6.2 and 6.3.
> The same command g.mremove in command line mode works well.
>
>
> -------------------------------------------- Managed by Request Tracker
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>   


Wed, Feb 7 2007 16:00:02    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17865.59758.189673.884182@cerise.gclements.plus.com>
Date Wed, 7 Feb 2007 14:59:58 +0000
To Markus Neteler <neteler@itc.it>
Cc Request Tracker <grass-bugs@intevation.de>, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
In-Reply-To <45C9A4F3.5040304@itc.it>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it>
X-Mailer VM 7.07 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Markus Neteler wrote:

> > Subject: g.mremove through gis manager GUI seems not to work well
> >
> > Platform: GNU/Linux/ppc
> > grass obtained from: Mirror of Trento site
> > grass binary for platform: Compiled from Sources
> > GRASS Version: GRASS6.2/6.3
> >
> > Aldo Clerici. 
> > The command File > Manage maps and volumes > Remove maps using expressions
and wildcards require an acknowledgment in the form:
> >
> > Collecting map names for current mapset <esercizi>....
> > g.remove rast=geology.new,slope.new
> > Did you mean this (y/n)?
> >
> > But it seems not to accept any kind of input (y,yes,n,no). It seems to wait
for something else.
> >   
> 
> Aldo,
> up to now interactive input in tcl based dialogs is not possible.
> Using the -f flag (force removal) you can delete also in gis.m.
> 
> Probably we need to enforce -f somehow in gis.m - how to do that?

I've committed a fix which removes the prompting code. The -f flag
remains for compatibility but is ignored.

-- 
Glynn Clements <glynn@gclements.plus.com>


Wed, Feb 7 2007 16:15:02    Mail sent by michael.barton@asu.edu  
Return-Path <michael.barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
User-Agent Microsoft-Entourage/11.3.3.061214
Date Wed, 07 Feb 2007 08:14:54 -0700
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
From Michael Barton <michael.barton@asu.edu>
To Markus Neteler <neteler@itc.it>, Paolo Cavallini via RT <grass-bugs@intevation.de>
Cc <grass-dev@grass.itc.it>
Message-ID <C1EF3AFE.1C252%michael.barton@asu.edu>
Thread-Topic [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
Thread-Index AcdKyrhY9rjMtra9Edu/WwAX8scpqg==
In-Reply-To <45C9A4F3.5040304@itc.it>
Mime-version 1.0
Content-type text/plain; charset="US-ASCII"
Content-transfer-encoding 7bit
X-Virus-Scanned by amavisd-new
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-3.752 tagged_above=-999 required=3 tests=[BAYES_00=-5, RCVD_NUMERIC_HELO=1.248]
X-Spam-Level
These kinds of interactive questions and often extraneous warnings seem to
be popping a lot recently. It's almost like they were built into the code
but not being triggered and some recent change has triggered them.

An especially annoying one warns me that map I am using is indeed the same
map that I am using in the mapset where I'm working.

The problem reported here hangs the code in the auto-generated gui dialogs
for modules, not the general GIS Manager gui. I haven't ventured into that
code much; Cedric Shock and Glynn Clements know it best. I suspect that
you're right and the -f flag needs to be added as a default when the module
is started without arguments (i.e., launches the module GUI).

The odd thing is that this was not happening until recently. So the larger
question is why are we now getting a lot of verbose warnings and interaction
request that didn't happen before?

Michael


On 2/7/07 3:07 AM, "Markus Neteler" <neteler@itc.it> wrote:

> Request Tracker wrote on 02/07/2007 10:59 AM:
>> this bug's URL: http://intevation.de/rt/webrt?serial_num=5483
>> -------------------------------------------------------------------------
>> 
>> Subject: g.mremove through gis manager GUI seems not to work well
>> 
>> Platform: GNU/Linux/ppc
>> grass obtained from: Mirror of Trento site
>> grass binary for platform: Compiled from Sources
>> GRASS Version: GRASS6.2/6.3
>> 
>> Aldo Clerici. 
>> The command File > Manage maps and volumes > Remove maps using expressions
>> and wildcards require an acknowledgment in the form:
>> 
>> Collecting map names for current mapset <esercizi>....
>> g.remove rast=geology.new,slope.new
>> Did you mean this (y/n)?
>> 
>> But it seems not to accept any kind of input (y,yes,n,no). It seems to wait
>> for something else.
>>   
> 
> Aldo,
> up to now interactive input in tcl based dialogs is not possible.
> Using the -f flag (force removal) you can delete also in gis.m.
> 
> Probably we need to enforce -f somehow in gis.m - how to do that?
> 
> Markus
> 
>> Same behaviour in grass6.2 and 6.3.
>> The same command g.mremove in command line mode works well.
>> 
>> 
>> -------------------------------------------- Managed by Request Tracker
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>>   
> 
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


Wed, Feb 7 2007 16:15:52    Mail sent by michael.barton@asu.edu  
Return-Path <michael.barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
User-Agent Microsoft-Entourage/11.3.3.061214
Date Wed, 07 Feb 2007 08:15:43 -0700
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
From Michael Barton <michael.barton@asu.edu>
To Glynn Clements <glynn@gclements.plus.com>, Markus Neteler <neteler@itc.it>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
Message-ID <C1EF3B2F.1C254%michael.barton@asu.edu>
Thread-Topic [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
Thread-Index AcdKytWNE+6rmLa+Edu/WwAX8scpqg==
In-Reply-To <17865.59758.189673.884182@cerise.gclements.plus.com>
Mime-version 1.0
Content-type text/plain; charset="US-ASCII"
Content-transfer-encoding 7bit
X-Virus-Scanned by amavisd-new
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-3.752 tagged_above=-999 required=3 tests=[BAYES_00=-5, RCVD_NUMERIC_HELO=1.248]
X-Spam-Level
I didn't read far enough in my mail list today. Thanks very much Glynn for
fixing this.

Michael


On 2/7/07 7:59 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Markus Neteler wrote:
> 
>>> Subject: g.mremove through gis manager GUI seems not to work well
>>> 
>>> Platform: GNU/Linux/ppc
>>> grass obtained from: Mirror of Trento site
>>> grass binary for platform: Compiled from Sources
>>> GRASS Version: GRASS6.2/6.3
>>> 
>>> Aldo Clerici. 
>>> The command File > Manage maps and volumes > Remove maps using expressions
>>> and wildcards require an acknowledgment in the form:
>>> 
>>> Collecting map names for current mapset <esercizi>....
>>> g.remove rast=geology.new,slope.new
>>> Did you mean this (y/n)?
>>> 
>>> But it seems not to accept any kind of input (y,yes,n,no). It seems to wait
>>> for something else.
>>>   
>> 
>> Aldo,
>> up to now interactive input in tcl based dialogs is not possible.
>> Using the -f flag (force removal) you can delete also in gis.m.
>> 
>> Probably we need to enforce -f somehow in gis.m - how to do that?
> 
> I've committed a fix which removes the prompting code. The -f flag
> remains for compatibility but is ignored.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


Wed, Feb 7 2007 16:53:19    Status changed to resolved by msieczka  
Wed, Feb 7 2007 16:53:19    Mail sent by msieczka  
Fixed by Glynn in CVS.

Closin it.

Maciek
Wed, Feb 7 2007 23:43:24    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 8 Feb 2007 11:38:27 +1300
From Hamish <hamish_nospam@yahoo.com>
To Glynn Clements <glynn@gclements.plus.com>
Cc neteler@itc.it, grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
Message-Id <20070208113827.56c056e0.hamish_nospam@yahoo.com>
In-Reply-To <17865.59758.189673.884182@cerise.gclements.plus.com>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
X-Spam-Level
Aldo:
> > > Subject: g.mremove through gis manager GUI seems not to work well
> > >
> > > The command File > Manage maps and volumes > Remove maps using
> > > expressions and wildcards require an acknowledgment in the form:
> > >
> > > Collecting map names for current mapset <esercizi>....
> > > g.remove rast=geology.new,slope.new
> > > Did you mean this (y/n)?
> > >
> > > But it seems not to accept any kind of input (y,yes,n,no). It
> > > seems to wait for something else.

Markus:
> > up to now interactive input in tcl based dialogs is not possible.
> > Using the -f flag (force removal) you can delete also in gis.m.
> > 
> > Probably we need to enforce -f somehow in gis.m - how to do that?

Glynn:
> I've committed a fix which removes the prompting code. The -f flag
> remains for compatibility but is ignored.

I understand the push to remove interactive, but this one is a fairly
important failsafe and I wouldn't mind it staying. With the -f flag a
non-interactive mode is available. An -i or --interactive flag as rm
uses could be added, but who would bother setting up an alias to use it?
Problably not the new users who would benefit from it the most.


To answer Markus's question, you can preset/hint an option's answer in
the GUI by giving it on the command line and adding the --ui switch to
force a GUI:

g.mremove -f --ui

I've backported a fix using this method to the 6.2 GUI menu.tcl:
 -command {execute "g.mremove -f --ui" }}


.. as for 6.3, ?


Hamish


Wed, Feb 7 2007 23:43:24    Status changed to open by _rt_system  
Wed, Feb 7 2007 23:48:29    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 8 Feb 2007 11:42:56 +1300
From Hamish <hamish_nospam@yahoo.com>
To Michael Barton <michael.barton@asu.edu>
Cc grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
Message-Id <20070208114256.55f87bd9.hamish_nospam@yahoo.com>
In-Reply-To <C1EF3AFE.1C252%michael.barton@asu.edu>
References <45C9A4F3.5040304@itc.it> <C1EF3AFE.1C252%michael.barton@asu.edu>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
X-Spam-Level
Michael Barton wrote:
> 
> These kinds of interactive questions and often extraneous warnings
> seem to be popping a lot recently. It's almost like they were built
> into the code but not being triggered and some recent change has
> triggered them.
..
> The odd thing is that this was not happening until recently. So the
> larger question is why are we now getting a lot of verbose warnings
> and interaction request that didn't happen before?

No, I think this is a long standing problem, nothing new.
Maybe we are just getting wider testing of the 6.2 code now?


> An especially annoying one warns me that map I am using is indeed the
> same map that I am using in the mapset where I'm working.

Can you cite a specfic command that triggers that & file it in a bug
report?


Hamish


Thu, Feb 8 2007 01:20:32    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 8 Feb 2007 00:20:27 +0000 (GMT)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
X-X-Sender paulk@agrippa.ukshells.co.uk
To Hamish <hamish_nospam@yahoo.com>
Cc Glynn Clements <glynn@gclements.plus.com>, neteler@itc.it, grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
In-Reply-To <20070208113827.56c056e0.hamish_nospam@yahoo.com>
Message-ID <Pine.LNX.4.62.0702080017440.8498@agrippa.ukshells.co.uk>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Do-Not-Run Yes
X-SA-Exim-Connect-IP 217.10.143.90
X-SA-Exim-Mail-From paul-grass@stjohnspoint.co.uk
X-SA-Exim-Scanned No (on mail.ukshells.net); SAEximRunCond expanded to false
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
On Thu, 8 Feb 2007, Hamish wrote:

> Markus:
>>> up to now interactive input in tcl based dialogs is not possible.
>>> Using the -f flag (force removal) you can delete also in gis.m.
>>>
>>> Probably we need to enforce -f somehow in gis.m - how to do that?
>
> Glynn:
>> I've committed a fix which removes the prompting code. The -f flag
>> remains for compatibility but is ignored.
>
> I understand the push to remove interactive, but this one is a fairly
> important failsafe and I wouldn't mind it staying. With the -f flag a

I agree this seems a bit of a dangerous change, especially since an easy 
workaround was available... hope it doesn't catch anybody out who is just 
experimenting with a wildcard pattern but not sure if it's the one they 
want! I know I have used it like that in the past anyway.

> non-interactive mode is available. An -i or --interactive flag as rm
> uses could be added, but who would bother setting up an alias to use it?
> Problably not the new users who would benefit from it the most.
>
>
> To answer Markus's question, you can preset/hint an option's answer in
> the GUI by giving it on the command line and adding the --ui switch to
> force a GUI:
>
> g.mremove -f --ui
>
> I've backported a fix using this method to the 6.2 GUI menu.tcl:
> -command {execute "g.mremove -f --ui" }}
>
>
> .. as for 6.3, ?
>
>
> Hamish
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


Thu, Feb 8 2007 12:33:53    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17867.2715.298187.307696@cerise.gclements.plus.com>
Date Thu, 8 Feb 2007 11:33:47 +0000
To Hamish <hamish_nospam@yahoo.com>
Cc neteler@itc.it, grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
In-Reply-To <20070208113827.56c056e0.hamish_nospam@yahoo.com>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com>
X-Mailer VM 7.07 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Hamish wrote:

> > > up to now interactive input in tcl based dialogs is not possible.
> > > Using the -f flag (force removal) you can delete also in gis.m.
> > > 
> > > Probably we need to enforce -f somehow in gis.m - how to do that?
> 
> > I've committed a fix which removes the prompting code. The -f flag
> > remains for compatibility but is ignored.
> 
> I understand the push to remove interactive, but this one is a fairly
> important failsafe and I wouldn't mind it staying. With the -f flag a
> non-interactive mode is available. An -i or --interactive flag as rm
> uses could be added, but who would bother setting up an alias to use it?
> Problably not the new users who would benefit from it the most.

A -i flag would be all well and good, *if* you could guarantee that
there was a terminal from which to obtain the user's response.

Fixing bugs (e.g. assuming the presence of a terminal) takes
precedence over implementing wishes (e.g. a -i flag).

There's also the issue that currently there's no way to tell the GUI
that it needs to either hide the -i flag from the user, or use an
xterm if the -i flag is enabled.

Ultimately, a module is either interactive or it isn't. If it's even
slightly interactive, then it's interactive, and that reduces its
usability.

> To answer Markus's question, you can preset/hint an option's answer in
> the GUI by giving it on the command line and adding the --ui switch to
> force a GUI:
> 
> g.mremove -f --ui
> 
> I've backported a fix using this method to the 6.2 GUI menu.tcl:
>  -command {execute "g.mremove -f --ui" }}

What happens if the user deselects the -f switch from the GUI? Is
there any way to kill the hung process?

-- 
Glynn Clements <glynn@gclements.plus.com>


Fri, Feb 9 2007 00:54:26    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 9 Feb 2007 12:54:08 +1300
From Hamish <hamish_nospam@yahoo.com>
To Glynn Clements <glynn@gclements.plus.com>
Cc grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
Message-Id <20070209125408.6eb1b737.hamish_nospam@yahoo.com>
In-Reply-To <17867.2715.298187.307696@cerise.gclements.plus.com>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <17867.2715.298187.307696@cerise.gclements.plus.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
X-Spam-Level
Glynn Clements wrote:
> > > I've committed a fix which removes the prompting code. The -f flag
> > > remains for compatibility but is ignored.

> Hamish wrote:
> > you can preset/hint an option's answer in the GUI by giving it on
> > the command line and adding the --ui switch to force a GUI:
> > 
> > g.mremove -f --ui
> > 
> > I've backported a fix using this method to the 6.2 GUI menu.tcl:
> >  -command {execute "g.mremove -f --ui" }}

Glynn:
> Ultimately, a module is either interactive or it isn't. If it's even
> slightly interactive, then it's interactive, and that reduces its
> usability.
..
> What happens if the user deselects the -f switch from the GUI? Is
> there any way to kill the hung process?

Then they get stuck. We'd have to change the option's description which
read: "-f (use only if you know what you are doing)". Users are likely
to deselect it based on that, esp if they are new.

Other alternatives:

* remove g.mremove from the GUI menu all together -- leave it as a power
tool from the command line if you know what you are doing.

* write a wrapper --script for g.mremove which doesn't include the -f
flag, and have the GUI call that.



Hamish


Sun, Feb 11 2007 12:58:22    Mail sent by tutey@o2.pl  
Return-Path <tutey@o2.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <45CF04CA.5060105@o2.pl>
Date Sun, 11 Feb 2007 12:58:02 +0100
From Maciej Sieczka <tutey@o2.pl>
User-Agent Thunderbird 1.5.0.9 (X11/20070104)
MIME-Version 1.0
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc Hamish <hamish_nospam@yahoo.com>, neteler@itc.it, grass-bugs@intevation.de, Glynn Clements <glynn@gclements.plus.com>, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <Pine.LNX.4.62.0702080017440.8498@agrippa.ukshells.co.uk>
In-Reply-To <Pine.LNX.4.62.0702080017440.8498@agrippa.ukshells.co.uk>
Content-Type text/plain; charset=ISO-8859-2
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Paul Kelly wrote:
> On Thu, 8 Feb 2007, Hamish wrote:
> 
>> Markus:
>>>> up to now interactive input in tcl based dialogs is not possible.
>>>> Using the -f flag (force removal) you can delete also in gis.m.
>>>>
>>>> Probably we need to enforce -f somehow in gis.m - how to do that?
>>
>> Glynn:
>>> I've committed a fix which removes the prompting code. The -f flag
>>> remains for compatibility but is ignored.
>>
>> I understand the push to remove interactive, but this one is a fairly
>> important failsafe and I wouldn't mind it staying. With the -f flag a
> 
> I agree this seems a bit of a dangerous change, especially since an easy
> workaround was available... hope it doesn't catch anybody out who is
> just experimenting with a wildcard pattern but not sure if it's the one
> they want! I know I have used it like that in the past anyway.

I'm uneasy about this change too. Users who knew how g.mremove worked
in past will be surprised the safety question has been removed. Some of
them will be surprised badly, learning it when a precious map is
removed with the rest of the crowd on a sudden, while the user expected
y/n prompt.

I was never really carefull when giving the wildcard to g.mremove.
Propably nobody was, since we knew g.mremove will let us me verify the
wildcard's result before deleting data. Now the wildcard has to be
perfect at a first attempt, which is a unrealistic requirement when you
have dozens of maps in the mapset.

I agree that the interactivity has to be removed when possible, but in
this case it is too radical change I guess. It would be all OK if
g.mremove never asked for confirmation. But since it used to, it's
behaviour as users knew it for years is changed, and this change will
lead to data loss and user frustration. I don't think such radical
changes, even as fixes, should be allowed during GRASS 6.

What do you think about this: if g.mremove cannot remain
half-interactive, I'd suggest getting rid of it alltogether, and
replacing it's manual page with an instruction how to use "g.mlist
sep=," and feed it's output to g.remove by hand (I can write it).
Although removing a module during GRASS 6 should be avoided too, I
think that this would do less harm than letting g.mremove delete user's
data without control.

Or maybe revert the changes in g.mremove as it was, for GRASS 6, and
postpone working on it to GRASS 7? As for GRASS 7, I'd still vote on
removing it completely, as described above, instead of removing it's
interactiveness, for the sake of user's data.

Maciek


Sun, Feb 11 2007 19:10:33    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17871.23570.679544.688973@cerise.gclements.plus.com>
Date Sun, 11 Feb 2007 18:10:26 +0000
To Maciej Sieczka <tutey@o2.pl>
Cc Paul Kelly <paul-grass@stjohnspoint.co.uk>, neteler@itc.it, grass-bugs@intevation.de, Hamish <hamish_nospam@yahoo.com>, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
In-Reply-To <45CF04CA.5060105@o2.pl>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <Pine.LNX.4.62.0702080017440.8498@agrippa.ukshells.co.uk> <45CF04CA.5060105@o2.pl>
X-Mailer VM 7.07 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Maciej Sieczka wrote:

> >>>> up to now interactive input in tcl based dialogs is not possible.
> >>>> Using the -f flag (force removal) you can delete also in gis.m.
> >>>>
> >>>> Probably we need to enforce -f somehow in gis.m - how to do that?
> >>
> >> Glynn:
> >>> I've committed a fix which removes the prompting code. The -f flag
> >>> remains for compatibility but is ignored.
> >>
> >> I understand the push to remove interactive, but this one is a fairly
> >> important failsafe and I wouldn't mind it staying. With the -f flag a
> > 
> > I agree this seems a bit of a dangerous change, especially since an easy
> > workaround was available... hope it doesn't catch anybody out who is
> > just experimenting with a wildcard pattern but not sure if it's the one
> > they want! I know I have used it like that in the past anyway.
> 
> I'm uneasy about this change too. Users who knew how g.mremove worked
> in past will be surprised the safety question has been removed. Some of
> them will be surprised badly, learning it when a precious map is
> removed with the rest of the crowd on a sudden, while the user expected
> y/n prompt.
> 
> I was never really carefull when giving the wildcard to g.mremove.
> Propably nobody was, since we knew g.mremove will let us me verify the
> wildcard's result before deleting data. Now the wildcard has to be
> perfect at a first attempt, which is a unrealistic requirement when you
> have dozens of maps in the mapset.
> 
> I agree that the interactivity has to be removed when possible, but in
> this case it is too radical change I guess. It would be all OK if
> g.mremove never asked for confirmation. But since it used to, it's
> behaviour as users knew it for years is changed, and this change will
> lead to data loss and user frustration. I don't think such radical
> changes, even as fixes, should be allowed during GRASS 6.

Okay, I can see your point here.

> What do you think about this: if g.mremove cannot remain
> half-interactive, I'd suggest getting rid of it alltogether, and
> replacing it's manual page with an instruction how to use "g.mlist
> sep=," and feed it's output to g.remove by hand (I can write it).
> Although removing a module during GRASS 6 should be avoided too, I
> think that this would do less harm than letting g.mremove delete user's
> data without control.
> 
> Or maybe revert the changes in g.mremove as it was, for GRASS 6, and
> postpone working on it to GRASS 7? As for GRASS 7, I'd still vote on
> removing it completely, as described above, instead of removing it's
> interactiveness, for the sake of user's data.

Alternative possibilities:

1. Rename g.mremove (e.g. to g.remove.multi); if anyone asks where it
went, remind them that the new version doesn't request confirmation.

2. Revert g.mremove, add a version which doesn't prompt, change gis.m
to only refer to the non-prompting version.

Personally, I'd favour #1; option #2 undermines attempts to get
developers to realise that terminal interaction is unacceptable.

In my experience, any rule with an "except in special cases" qualifier
may as well not exist. Everyone thinks that their pet case qualifies,
and you end up with a useless mess.

Either you can rely upon GRASS commands being scriptable, or you
can't. Right now, you can't; if you try to build something on top of
GRASS, sooner or later something is going to try to prompt the
non-existent user for input which will never arrive.

-- 
Glynn Clements <glynn@gclements.plus.com>


Mon, Feb 12 2007 10:23:49    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Mon, 12 Feb 2007 22:23:33 +1300
From Hamish <hamish_nospam@yahoo.com>
To Glynn Clements <glynn@gclements.plus.com>
Cc tutey@o2.pl, paul-grass@stjohnspoint.co.uk, grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
Message-Id <20070212222333.4932aebe.hamish_nospam@yahoo.com>
In-Reply-To <17871.23570.679544.688973@cerise.gclements.plus.com>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <Pine.LNX.4.62.0702080017440.8498@agrippa.ukshells.co.uk> <45CF04CA.5060105@o2.pl> <17871.23570.679544.688973@cerise.gclements.plus.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type multipart/mixed; boundary="Multipart=_Mon__12_Feb_2007_22_23_33_+1300_dlK3Ym/h.XOlzA=/"
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-1.498 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7, MULTI_REMOVAL_1WORD=0.802]
X-Spam-Level
This is a multi-part message in MIME format.

--Multipart=_Mon__12_Feb_2007_22_23_33_+1300_dlK3Ym/h.XOlzA=/
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Maciej:
> > What do you think about this: if g.mremove cannot remain
> > half-interactive, I'd suggest getting rid of it alltogether, and
> > replacing it's manual page with an instruction how to use "g.mlist
> > sep=," and feed it's output to g.remove by hand (I can write it).

No, just remove it from the GUI if the possibility of interactivity is
an issue, or create a wrapper script for the GUI which does not include
the offending flag. I don't think it is so bad to have command-line-only
power-tools, and to leave g.mremove out of the GUI if that's what is
required.

> > Although removing a module during GRASS 6 should be avoided too, I
> > think that this would do less harm than letting g.mremove delete
> > user's data without control.

Removing a module during GRASS 6 should not be allowed at all.
That will break scripts and render documentation+books out of date.

> > Or maybe revert the changes in g.mremove as it was, for GRASS 6, and
> > postpone working on it to GRASS 7? As for GRASS 7, I'd still vote on
> > removing it completely, as described above, instead of removing it's
> > interactiveness, for the sake of user's data.

Glynn:
> Alternative possibilities:
> 
> 1. Rename g.mremove (e.g. to g.remove.multi); if anyone asks where it
> went, remind them that the new version doesn't request confirmation.
> 
> 2. Revert g.mremove, add a version which doesn't prompt, change gis.m
> to only refer to the non-prompting version.
> 
> Personally, I'd favour #1; option #2 undermines attempts to get
> developers to realise that terminal interaction is unacceptable.

Personally I'd prefer #2 or removing g.mremove from the GUI menu vs.
adding yet another duplicate module.

but wait --

** A compromise idea: make g.mremove without "-f" exit (0 or 1?) after
listing the files the regex would match; have it only delete something
if "-f" is used. The extra tick of brain activity to type the extra 3
chars should be enough to invoke the do-I-really-want-to-do-this 2nd
thought, if not, well that's not our problem, we tried. That way we only
"break" interactive mode, and the new solution is in a way interactive
(they have to retype the command).

 -- patch attached.

> In my experience, any rule with an "except in special cases" qualifier
> may as well not exist. Everyone thinks that their pet case qualifies,
> and you end up with a useless mess.
>
> Either you can rely upon GRASS commands being scriptable, or you
> can't. Right now, you can't;

Point taken.

> if you try to build something on top of GRASS, sooner or later
> something is going to try to prompt the non-existent user for input
> which will never arrive.

It's a worthy goal, and something we should do for GRASS 7, but we can't
go around breaking people's scripts in order to make their scripts
easier to write! [Glynn's patch in CVS does not do that; some of the
proposed solutions might] As far as g.mremove goes, I imagine scripters
figured out they needed to use "-f" when they wrote it.


So how do folks feel about the compromise solution? Without -f it skips
the y/n prompt, forcing "no", and a functional g.remove command line is
sent to stdout for perusal[, piping, logging, whatever], along with a
message to stderr that you need to use -f if you actually want to remove
files.


Hamish

--Multipart=_Mon__12_Feb_2007_22_23_33_+1300_dlK3Ym/h.XOlzA=/
Content-Type: text/plain;
 name="mremove_force.diff"
Content-Disposition: attachment;
 filename="mremove_force.diff"
Content-Transfer-Encoding: 7bit

Index: scripts/g.mremove/g.mremove
===================================================================
RCS file: /home/grass/grassrepository/grass6/scripts/g.mremove/g.mremove,v
retrieving revision 1.11
diff -u -r1.11 g.mremove
--- scripts/g.mremove/g.mremove	7 Feb 2007 14:58:49 -0000	1.11
+++ scripts/g.mremove/g.mremove	12 Feb 2007 09:09:05 -0000
@@ -28,7 +28,7 @@
 
 #%flag
 #%  key: f
-#%  description: ignored (retained for compatibility with previous versions)
+#%  description: force removal (required for actual deletion of files)
 #%end
 
 #%option
@@ -205,5 +205,14 @@
 	echo "No data found."
 	exit 1
 fi
+
+if [ $force -eq 0 ] ; then
+    echo "The following files would be deleted:" 1>&2
+    echo "g.remove $rast $rast3d $vect $icon $labels $region $group $dview"
+    echo 1>&2
+    echo "You must use the force flag to actually remove them. Exiting." 1>&2
+    exit 0
+fi
+
 
 exec g.remove $rast $rast3d $vect $icon $labels $region $group $dview

--Multipart=_Mon__12_Feb_2007_22_23_33_+1300_dlK3Ym/h.XOlzA=/--


Mon, Feb 12 2007 14:54:13    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17872.29054.270882.740460@cerise.gclements.plus.com>
Date Mon, 12 Feb 2007 13:54:06 +0000
To Hamish <hamish_nospam@yahoo.com>
Cc grass-bugs@intevation.de, paul-grass@stjohnspoint.co.uk, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
In-Reply-To <20070212222333.4932aebe.hamish_nospam@yahoo.com>
References <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <Pine.LNX.4.62.0702080017440.8498@agrippa.ukshells.co.uk> <45CF04CA.5060105@o2.pl> <17871.23570.679544.688973@cerise.gclements.plus.com> <20070212222333.4932aebe.hamish_nospam@yahoo.com>
X-Mailer VM 7.07 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5]
X-Spam-Level
Hamish wrote:

> but wait --
> 
> ** A compromise idea: make g.mremove without "-f" exit (0 or 1?) after
> listing the files the regex would match; have it only delete something
> if "-f" is used. The extra tick of brain activity to type the extra 3
> chars should be enough to invoke the do-I-really-want-to-do-this 2nd
> thought, if not, well that's not our problem, we tried. That way we only
> "break" interactive mode, and the new solution is in a way interactive
> (they have to retype the command).

That's a good idea.

> > if you try to build something on top of GRASS, sooner or later
> > something is going to try to prompt the non-existent user for input
> > which will never arrive.
> 
> It's a worthy goal, and something we should do for GRASS 7, but we can't
> go around breaking people's scripts in order to make their scripts
> easier to write! [Glynn's patch in CVS does not do that; some of the
> proposed solutions might] As far as g.mremove goes, I imagine scripters
> figured out they needed to use "-f" when they wrote it.

Note that my patch retained the -f flag, although the script doesn't
pay any attention to it. Any scripts using "g.mremove -f ..." would
work as before.

> So how do folks feel about the compromise solution? Without -f it skips
> the y/n prompt, forcing "no", and a functional g.remove command line is
> sent to stdout for perusal[, piping, logging, whatever], along with a
> message to stderr that you need to use -f if you actually want to remove
> files.

Seems okay to me.

1. -f works as before.

2. Omitting -f won't unconditionally delete files which wouldn't have
been unconditionally deleted before.

3. The changed behaviour when -f is omitted isn't really a problem as
that case always required user interaction.

4. It still "works" (i.e. doesn't hang) if a terminal isn't available.

-- 
Glynn Clements <glynn@gclements.plus.com>


Mon, Feb 12 2007 22:58:31    Mail sent by msieczka  
glynn@gclements.plus.com wrote (Mon, Feb 12 2007 14:54:13):

> Hamish wrote:
> 
> > but wait --
> > 
> > ** A compromise idea: make g.mremove without "-f" exit (0 or 1?) after
> > listing the files the regex would match; have it only delete something
> > if "-f" is used. The extra tick of brain activity to type the extra 3
> > chars should be enough to invoke the do-I-really-want-to-do-this 2nd
> > thought, if not, well that's not our problem, we tried. That way we only
> > "break" interactive mode, and the new solution is in a way interactive
> > (they have to retype the command).
> 
> That's a good idea.

I like it too.

Maciek
Tue, Feb 13 2007 00:37:08    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 13 Feb 2007 12:37:01 +1300
From Hamish <hamish_nospam@yahoo.com>
To Maciek Sieczka via RT <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well
Message-Id <20070213123701.6143712d.hamish_nospam@yahoo.com>
In-Reply-To <20070212215831.6C5831006B5@lists.intevation.de>
References <20070212215831.6C5831006B5@lists.intevation.de>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-2.3 tagged_above=-999 required=3 tests=[BAYES_00=-5, FORGED_YAHOO_RCVD=2.7]
X-Spam-Level
Hamish:
> > > but wait --
> > > 
> > > ** A compromise idea: make g.mremove without "-f" exit (0 or 1?)
> > > after listing the files the regex would match; have it only delete
> > > something if "-f" is used. The extra tick of brain activity to
> > > type the extra 3 chars should be enough to invoke the
> > > do-I-really-want-to-do-this 2nd thought, if not, well that's not
> > > our problem, we tried. That way we only "break" interactive mode,
> > > and the new solution is in a way interactive (they have to retype
> > > the command).
Glynn:
> > That's a good idea.
Maciek:
> I like it too.


done in 6.3 and 6.2 cvses.


Hamish


Tue, Feb 13 2007 00:37:53    Status changed to resolved by hbowman  
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