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)
|
|