Details Ticket 3009


Comment | Reply | Take | Resolve


Serial Number 3009
Subject g.remove - accidental removing possible!
Area wish6
Queue grass
Requestors Morten.Sickel@newmedia.no,jidanni@dman.ddts.net,tutey@o2.pl
Owner none
Status open
Last User Contact Thu Feb 24 03:19:00 2005 (4 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Jul 26 14:22:48 2006 (2 yr ago)
Created Thu Nov 1 08:44:48 2001 (7 yr ago)

Transaction History Ticket 3009


Thu, Nov 1 2001 08:44:48    Request created by guest (as #820)  
Subject: Idea: links for g.remove, g.list,, g.rename maybe others

Platform: Linux/Intel
Linux distro: RedHat
linux cpu: AMD (K6, ...)
Xwindows version: Xfree 3.3.6
Xwindows manager: KDE 2.x
TclTk version: tcl/tk 8.2
grass downloaded at: Hannover site
grass binary for platform: I compiled the sources myself
grass sources source: no, I got a source code package from the server, pre-2
c compiler name: gcc

Regarding the commands for general cover management i.e g.copy, g.rename, g.remove,
g.list (maybe also others) could it be possible (at least in unix..) to make
links to the same command for each data type? 
In stead of writing g.list rast, I could write r.list and have a list of raster
files, in stead of writing g.copy vect=vector1,vector2, I could write v.copy
vector1 vector2 etc. For systems that do not support multiple links to a file,
different versions of the commands could of cource be used.

Related to this:
g.remove behaves almost as I would like to... if no data type specifier is given,
it defaults to rast. IMHO that is quite dangerous. If I want to remove the vector
cover my_dear_map and manages to writes g.remove my_dear_map (because that is
more similiar to a typical unix shell command), it removes quite happily the
raster file my_dear_map.... 
Fri, Nov 2 2001 13:56:39    Mail sent by neteler@itc.it (as #820)  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@mailman.intevation.de
Date Fri, 2 Nov 2001 13:56:30 +0100
From Markus Neteler <neteler@itc.it>
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #820] (grass) Idea: links for g.remove, g.list,, g.rename maybe others
Message-ID <20011102135629.F10838@itc.it>
Mail-Followup-To Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20011101074448.86CB913A07@mailman.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5i
In-Reply-To <20011101074448.86CB913A07@mailman.intevation.de>; from grass-bugs@intevation.de on Thu, Nov 01, 2001 at 08:44:48AM +0100
On Thu, Nov 01, 2001 at 08:44:48AM +0100, Request Tracker wrote:
> Related to this:
> g.remove behaves almost as I would like to... if no data
> type specifier is given, it defaults to rast. IMHO that is quite
> dangerous. If I want to remove the vector cover my_dear_map and manages to
> writes g.remove my_dear_map (because that is more similiar to a typical
> unix shell command), it removes quite happily the raster file
> my_dear_map....

Hi,

I agree - at least for g.remove [g.mremove] there should be no default
data type to avoid above potential problem.

Any objections to change g.remove?

Markus


Fri, Nov 9 2001 13:38:02    Mail sent by glynn.clements@virgin.net (as #820)  
Return-Path <glynn.clements@virgin.net>
Delivered-To grass-bugs@mailman.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 <15339.52609.606317.963762@cerise.nosuchdomain.co.uk>
Date Fri, 9 Nov 2001 12:35:13 +0000
To Markus Neteler <neteler@itc.it>
Cc Request Tracker <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #820] (grass) Idea: links for g.remove, g.list,, g.rename maybe others
In-Reply-To <20011102135629.F10838@itc.it>
References <20011101074448.86CB913A07@mailman.intevation.de> <20011102135629.F10838@itc.it>
X-Mailer VM 6.94 under 21.4 (patch 4) "Artificial Intelligence (candidate #1)" XEmacs Lucid
Markus Neteler wrote:

> On Thu, Nov 01, 2001 at 08:44:48AM +0100, Request Tracker wrote:
> > Related to this:
> > g.remove behaves almost as I would like to... if no data
> > type specifier is given, it defaults to rast. IMHO that is quite
> > dangerous. If I want to remove the vector cover my_dear_map and manages to
> > writes g.remove my_dear_map (because that is more similiar to a typical
> > unix shell command), it removes quite happily the raster file
> > my_dear_map....
> 
> I agree - at least for g.remove [g.mremove] there should be no default
> data type to avoid above potential problem.
> 
> Any objections to change g.remove?

No objection; but how do you intend to implement it?

AFAICT, the behaviour in question is built into G_parser(). An
argument which neither begins with a dash nor contains an equals sign
is treated as the value of the first (non-flag) option.

You could add a dummy option to the beginning of the list, but then
that would show up in the "help" and "--interface-description" output,
which isn't ideal. OTOH, it isn't as bad as inadvertently deleting the
wrong map.

Is it worth extending G_parser() for this case?

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


Fri, Nov 9 2001 18:56:50    User changed to by bernhard (as #820)  
Fri, Nov 9 2001 18:57:24    User changed to neteler@itc.it by bernhard (as #820)  
Fri, Nov 9 2001 19:00:07    User changed to Morten.Sickel@newmedia.no by bernhard (as #820)  
Fri, Nov 9 2001 19:00:40    Comments added by bernhard (as #820)  
Morten's email address was wrong.
Fri, Nov 16 2001 17:32:39    Mail sent by neteler@itc.it (as #820)  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Resent-Message-Id <200111161632.fAGGWZA29866@thuille.itc.it.>
From Markus Neteler <neteler@itc.it>
To grass5@grass.itc.it
Subject Re: [GRASS5] [bug #820] (grass) Idea: links for g.remove, g.list,, g.rename maybe others
Message-ID <20011109135158.O3852@itc.it>
Mail-Followup-To grass5@grass.itc.it
References <20011101074448.86CB913A07@mailman.intevation.de> <20011102135629.F10838@itc.it> <15339.52609.606317.963762@cerise.nosuchdomain.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
User-Agent Mutt/1.2.5i
In-Reply-To <15339.52609.606317.963762@cerise.nosuchdomain.co.uk>; from glynn.clements@virgin.net on Fri, Nov 09, 2001 at 12:35:13PM +0000
Sender grass5-admin@grass.itc.it
Errors-To grass5-admin@grass.itc.it
X-BeenThere grass5@grass.itc.it
X-Mailman-Version 2.0.5
Precedence bulk
List-Help <mailto:grass5-request@grass.itc.it?subject=help>
List-Post <mailto:grass5@grass.itc.it>
List-Subscribe <http://grass.itc.it/mailman/listinfo/grass5>, <mailto:grass5-request@grass.itc.it?subject=subscribe>
List-Id GRASS 5 Developers mailing list <grass5.grass.itc.it>
List-Unsubscribe <http://grass.itc.it/mailman/listinfo/grass5>, <mailto:grass5-request@grass.itc.it?subject=unsubscribe>
List-Archive <http://grass.itc.it/pipermail/grass5/>
Date Fri, 9 Nov 2001 13:51:58 +0100
Resent-From neteler@itc.it
Resent-Date Fri, 16 Nov 2001 17:32:35 +0100
Resent-To grass-bugs@intevation.de
On Fri, Nov 09, 2001 at 12:35:13PM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > On Thu, Nov 01, 2001 at 08:44:48AM +0100, Request Tracker wrote:
> > > Related to this:
> > > g.remove behaves almost as I would like to... if no data
> > > type specifier is given, it defaults to rast. IMHO that is quite
> > > dangerous. If I want to remove the vector cover my_dear_map and manages
to
> > > writes g.remove my_dear_map (because that is more similiar to a typical
> > > unix shell command), it removes quite happily the raster file
> > > my_dear_map....
> > 
> > I agree - at least for g.remove [g.mremove] there should be no default
> > data type to avoid above potential problem.
> > 
> > Any objections to change g.remove?
> 
> No objection; but how do you intend to implement it?
> 
> AFAICT, the behaviour in question is built into G_parser(). An
> argument which neither begins with a dash nor contains an equals sign
> is treated as the value of the first (non-flag) option.

yes, I didn't think of that.
 
> You could add a dummy option to the beginning of the list, but then
> that would show up in the "help" and "--interface-description" output,
> which isn't ideal. OTOH, it isn't as bad as inadvertently deleting the
> wrong map.
> 
> Is it worth extending G_parser() for this case?

Maybe not. But what about simply changing the order to have
[icon=name[,name,...]] at the beginning? Only a few percent of the users
will use icons, so the probability to delete an icon because of having a
raster map with the same name is pretty low. This would solve the
problem easily.

Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5


Fri, Nov 16 2001 17:32:51    Priority changed to 70 by mneteler (as #820)  
Fri, Jan 4 2002 16:59:16    Comments added by alange (as #820)  
Hi,

it is not possible to change the occurence of the different list elements, as
the range for the command line is dynamically allocated from etc/element_list.
Is the problem still prevalent? Are there any suggestions?

Andreas
Sun, Mar 24 2002 20:16:45    Priority changed to 30 by mneteler (as #820)  
Thu, Nov 7 2002 05:30:08    Request created by guest (as #1399)  
Subject: g.remove some files easier than others

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: 5.0pre1

g.remove some_raster_file
works right on the command line,
but for 3dview files one must say 3dview=name

My point is that raster files seem the default, but this is 
not documented on the man page, and therefore should be.
Thu, Nov 7 2002 06:44:10    Mail sent by glynn.clements@virgin.net (as #1399)  
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 <15817.64646.516333.860086@cerise.nosuchdomain.co.uk>
Date Thu, 7 Nov 2002 05:39:18 +0000
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #1399] (grass) g.remove some files easier than others
In-Reply-To <20021107043008.E436513A3E@lists.intevation.de>
References <20021107043008.E436513A3E@lists.intevation.de>
X-Mailer VM 6.94 under 21.4 (patch 10) "Military Intelligence" XEmacs Lucid
X-Spam-Status No, hits=-12.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02 version=2.41
X-Spam-Level
Request Tracker wrote:

> g.remove some_raster_file
> works right on the command line,
> but for 3dview files one must say 3dview=name
> 
> My point is that raster files seem the default, but this is 
> not documented on the man page, and therefore should be.

According to the g.remove manpage, you must always specify the element
type, e.g.

	g.remove rast=name
	g.remove 3dview=name

etc.

There is nothing in the g.remove manpage which suggests that

	g.remove name

will work; the fact that it does is an artifact of the generic
command-line parser, which always allows the first option name to be
omitted.

If this should be documented anywhere, it should be in the parser(1)
manpage (which currently doesn't provide much information other than
to refer to the programmer's manual).

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


Sat, Nov 9 2002 01:01:53    Mail sent by jidanni@dman.ddts.net (as #1399)  
Return-Path <jidanni@dman.ddts.net>
Delivered-To grass-bugs@lists.intevation.de
To Glynn Clements via RT <grass-bugs@intevation.de>
Subject Re: [bug #1399] (grass) g.remove some files easier than others
References <20021107054410.7320B13A3E@lists.intevation.de>
In-Reply-To <20021107054410.7320B13A3E@lists.intevation.de>
From Dan Jacobson <jidanni@dman.ddts.net>
Date 09 Nov 2002 05:53:06 +0800
Message-ID <877kfnwwxp.fsf@jidanni.org>
Lines 20
User-Agent Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Spam-Status No, hits=-9.3 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT version=2.41
X-Spam-Level
>>>>> "RT" == Glynn Clements via RT <grass-bugs@intevation.de> writes:

RT> There is nothing in the g.remove manpage which suggests that

RT> 	g.remove name

RT> will work; the fact that it does is an artifact of the generic
RT> command-line parser, which always allows the first option name to be
RT> omitted.

Ah, so that's what's going on in so many commands! Ah ha.

RT> If this should be documented anywhere, it should be in the parser(1)
RT> manpage (which currently doesn't provide much information other than
RT> to refer to the programmer's manual).

Yes, not only on the parser man page, which no beginner will read, but
also in some introductory documents, along with a statement as to can
the user depend on this shortcut being around in the future, or is it
deprecated.


Fri, Feb 18 2005 00:06:07    Request created by guest  
Subject: g.remove - accidental removing possible!

Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot_2005_01_22

If the user doesn't specify the 'type' in g.remove then raster is taken as a
default, which may lead to accidental removing what you not intended to. Seems
scarry.

Example:

1. one wants to remove a vector named 'map'
2. he is somewhat likely to type 'g.remove map' forgetting to specify 'vect='
3. accidently there is also a raster called 'map' in his mapset
3. disaster, raster gone

Actualy it happened to me once. I suggest that there was no default target at
all. Just in case.

g.mremove suffers the same problem!

I also suggest to resign of default raster target for g.copy too and any other
using this scheme.

Maciek
Sun, Feb 20 2005 06:56:42    Mail sent by hbowman  
To prevent this I usually make the output of v.to.rast or whatever use a
capital first letter for the map name.

I think the benefits of not having to enter the default option= part for every
command outweighs the harm of the occasional deleted map. Perhaps there could
be a test for a g.gisenv variable like the OVERWRITE one to ask "Are you
sure"? This could be disabled by power users; needs a Yes/No GUI [see
g.message emails on grass5 list]



bug changed to wish.


Hamish
Sun, Feb 20 2005 06:57:17    Area changed to wish by hbowman  
Sun, Feb 20 2005 13:24:31    Mail sent by werchowyna@pf.pl  
Return-Path <werchowyna@pf.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <007701c51747$357a46d0$3fd21d3e@eustahiush>
From "Maciek Sieczka" <werchowyna@pf.pl>
To "Harmish Bowman via RT" <grass-bugs@intevation.de>
Cc "Hamish" <hamish_nospam@yahoo.com>
References <20050220055642.63AF3102BE0@lists.intevation.de>
Subject Re: [bug #3009] (grass) g.remove - accidental removing possible!
Date Sun, 20 Feb 2005 13:22:11 +0100
MIME-Version 1.0
Content-Type text/plain; format=flowed; charset="iso-8859-2"; reply-type=original
Content-Transfer-Encoding 7bit
X-Priority 3
X-MSMail-Priority Normal
X-Mailer Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE Produced By Microsoft MimeOLE V6.00.2900.2180
X-Antivirus avast! (VPS 0507-3, 2005-02-17), Outbound message
X-Antivirus-Status Clean
X-Spam-Status No, hits=-3.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, REMOVE_REMOVAL_2WORD
X-Spam-Level
From: "Harmish Bowman via RT" <grass-bugs@intevation.de>

Subject: [bug #3009] (grass) g.remove - accidental removing possible!


> To prevent this I usually make the output of v.to.rast or whatever use a
> capital first letter for the map name.

What if my rast map is not a product of v.to.rast - but still I have a 
vector and raster map with identical names? And how am I supposed to handle 
this uppercase/lowercase workaround properly when working quickly in a 
jungle of dozens of files?

> I think the benefits of not having to enter the default option= part for 
> every
> command outweighs the harm of the occasional deleted map.

And I don't :). Safety, reliability and idiot-proofness (to the possible 
extent) first.

Besides - since uniform, predictable behaviour is possible to achieve, why 
not implement it? By now g.remove, g.mremove,  g.rename and g.copy do not 
treat raster files and all the other types equally. And why to assume that 
Grass users will be working more with raster data than with vector, rast3d, 
asciivect,  sites etc., especially now when Grass' new vector engine 
attracts more vector-oriented GIS users?

> Perhaps there could be a test for a g.gisenv variable like the OVERWRITE
> one to ask "Are you sure"? This could be disabled by power users; needs
> a Yes/No GUI [see g.message emails on grass5 list]

I don't find it more practical than removing the default target permanently.
I'm *guessing* it might be the same amount of work to code it, but the 
resulting solution wouldn't be any better.

> bug changed to wish.

Right, my fault.

P.S.
I didn't CC to the grass5 list because you answered directly to me, but I 
have a temptation to invite folks to this discussion. If you don't mind it 
too - please forward to grass5 list.

Cheers

Maciek 


Tue, Feb 22 2005 03:33:35    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 22 Feb 2005 15:33:27 +1300
From Hamish <hamish_nospam@yahoo.com>
To "Maciek Sieczka" <werchowyna@pf.pl>
Cc grass-bugs@intevation.de
Subject Re: [bug #3009] (grass) g.remove - accidental removing possible!
Message-Id <20050222153327.0a8b75a4.hamish_nospam@yahoo.com>
In-Reply-To <007701c51747$357a46d0$3fd21d3e@eustahiush>
References <20050220055642.63AF3102BE0@lists.intevation.de> <007701c51747$357a46d0$3fd21d3e@eustahiush>
X-Mailer Sylpheed version 1.0.0 (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-Spam-Status No, hits=-2.1 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD, REMOVE_REMOVAL_2WORD
X-Spam-Level
> What if my rast map is not a product of v.to.rast - but still I have a

that was just an example of when you'd be likely to have two maps of the
same name..


> vector and raster map with identical names? And how am I supposed to
> handle  this uppercase/lowercase workaround properly when working
> quickly in a  jungle of dozens of files?

that's just something I use; derivative maps start with a capital
letter. Helps to find maps quickly with the 'locate' program too.
just provided as a tip.


> > I think the benefits of not having to enter the default option= part
> > for  every command outweighs the harm of the occasional deleted map.
> 
> And I don't :). Safety, reliability and idiot-proofness (to the
> possible  extent) first.

In general I agree with that fully; in this case it happens to screw up
pretty much every GRASS script ever written so I am hesitant to change
it. e.g. you'd have to then do "d.mon start=x0" not just "d.mon x0" etc.
In addition to breaking a lot of scripts anything that requires extra
keystrokes slows down power users and is to be avoided if possible.


> Besides - since uniform, predictable behaviour is possible to achieve,
> why  not implement it? By now g.remove, g.mremove,  g.rename and
> g.copy do not  treat raster files and all the other types equally. And
> why to assume that  Grass users will be working more with raster data
> than with vector, rast3d,  asciivect,  sites etc., especially now when
> Grass' new vector engine  attracts more vector-oriented GIS users?

It is this way for historical reasons of course. GRASS -was- a raster
based GIS for the most part, so default actions acted on raster files. 
So until there is a major re-write, the entire architecture is biased
towards rasters for good or ill.


> > Perhaps there could be a test for a g.gisenv variable like the
> > OVERWRITE one to ask "Are you sure"? This could be disabled by power
> > users; needs a Yes/No GUI [see g.message emails on grass5 list]
> 
> I don't find it more practical than removing the default target
> permanently.  I'm *guessing* it might be the same amount of work to
> code it, but the  resulting solution wouldn't be any better.

Removing the default target incurs problems as stated above.
Amount of coding is not really the issue.


> P.S.
> I didn't CC to the grass5 list because you answered directly to me,
> but I  have a temptation to invite folks to this discussion.

feel free. bugtracker is open to everybody.



regards,
Hamish


Thu, Feb 24 2005 03:19:00    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 24 Feb 2005 15:18:36 +1300
From Hamish <hamish_nospam@yahoo.com>
To "Maciek Sieczka" <werchowyna@pf.pl>
Cc grass5@grass.itc.it, grass-bugs@intevation.de
Subject Re: [bug #3009] (grass) g.remove - accidental removing possible!
Message-Id <20050224151836.01e599f7.hamish_nospam@yahoo.com>
In-Reply-To <013f01c5192d$bd4781d0$01c61d3e@eustahiush>
References <013f01c5192d$bd4781d0$01c61d3e@eustahiush>
X-Mailer Sylpheed version 1.0.0 (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-Spam-Status No, hits=-2.1 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD, REMOVE_REMOVAL_2WORD
X-Spam-Level
> in respect to g.remove,  g.mremove, g.rename and g.copy.
[...]
> > in this case it happens to screw up pretty much every GRASS script
> > ever written so I am hesitant to change it. e.g. you'd have to then
> > do "d.mon start=x0" not just "d.mon x0" etc.
> 
> This is unrelated - d.mon is not a file-management command and it
> cannot do any harm to you whatever you use it.

To explain more fully:  to remove the default target in a GRASS module
you have to remove it in the parser library functions. You can't turn
this off for certain modules. Changing it would affect all modules.

You could move the default target away by changing which option comes
first, but the problem remains. If you did manage to rewrite the C and
script parsers to disable default option targets for a certain list
of modules you would still be breaking lots of scripts, which is to be
avoided unless the rewards are great.


> > In addition to breaking a lot of scripts anything that requires
> > extra keystrokes slows down power users and is to be avoided if
> > possible
> 
> Power users first? Hmm, doesn't sound inviting to Grass adepts.

I think everyone agrees that GRASS should aim to support the needs of
both new users and experienced users alike. It does not have to be
either/or.



Hamish


Fri, Sep 2 2005 18:37:29    User changed to werchowyna@epf.pl by msieczka  
Fri, Sep 2 2005 18:37:36    Area changed to wish6 by msieczka  
Thu, Feb 16 2006 21:58:11    Area changed to wish6 by msieczka (as #820)  
Sat, Jun 17 2006 13:20:27    Area changed to wish6 by msieczka (as #1399)  
Sat, Jun 17 2006 13:20:32    Request 1399 merged into 3009 by msieczka (as #1399)  
Wed, Jul 26 2006 14:22:48    User changed to jidanni@dman.ddts.net,tutey@o2.pl by msieczka  
Wed, Jul 26 2006 19:43:15    Subject changed to links for g.remove, g.list, g.rename maybe others by msieczka (as #820)  
Wed, Jul 26 2006 19:43:31    Request 820 merged into 3009 by msieczka (as #820)  
Comment | Reply | Take | Resolve

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