Maciej Sieczka wrote:
>>>> Propably due to the recent work on --v and --q flags (great stuff, many
>>>> thanks to the authors!), r.mapcalc doesn't print any progress indicator
>>>> anymore.
>>> AFAIK, modules are quiet by default now. If you want verbosity (e.g.
>>> progress indication) you have to enable it.
>> I didn't realize that quiet mode implies no progress indicator. In that
>> case verbose should be the default IMO, because we can't leave users
>> without a feedback from the module progress unless they implicitely
>> requests that. Am I wrong?
> Yes. The normal behaviour for Unix command-line programs is not to
> print anything unless something unexpected happens.
GRASS modules are not 'normal UNIX programs'. A user must be informed
if there's a progress. Otherwise he will not even know if the module
freezed or what. I fully second what Hamish says in this regard (in his
post in this thread).
On that, we'll just have to disagree. It isn't important, as the user
can just set GRASS_VERBOSE explicitly if the default value isn't to
their liking.
> Apart from anything else, generating an error at the point that the
> specific map is processed (the way that vectors are currently handled)
> means that it won't even attempt to remove any subsequent maps. E.g.
>
> g.remove vect=vect1,vectnonexist,vect2
>
> will abort on vectnonexist and won't attempt to remove vect2.
Fine. Then g.remove vect should be fixed to behave like the other
types, and a non-fatal "WARNING: Vector map <dummy> not found" shoud be
issued if needed. Same for all other types. And, most importantly,
those warnings should issued by default, unless the user requests
g.remove to run quietly (which implies that a verbose mode should be
the default). Otherwise the user will not know that the map he tried to
remove doesn't exist.
Warnings are supposed to be issued even at minimum verbosity. It's the
more detailed output which needs to vary according the verbosity
settings.
>> Also, in the verbose mode, only a single-line information like "Raster
>> map <dummy> removed" should be printed insated of the current 9 lines:
>>
>> $ g.remove rast=dummy --v
>> REMOVE [dummy]
>> raster
>> header
>> category
>> color MISSING
>> history
>> misc
>> fcell MISSING
>> g3dcell MISSING
> IMHO, verbose mode should display everything, quiet mode should
> display a single warning for each map with no elements (i.e. the map
> doesn't exist).
But all those lines: raster, header, category, color, history, misc,
fcell are meaningless for a normal user. He should only be told that
"Raster map <blahblah> was removed". Why does one need to read all
those lines anyway? They don't give any usefull information but
distract and occupy space on the terminal. They should be displayed
only at a higher DEBUG level.
In retrospect, I agree that those should be considered "debug"
information. Historically, they have been the only way to discover
that a map is entirely absent.
BTW, etc/element_list doesn't distinguish between "core" elements
(e.g. cellhd, cell etc) and ancilliary elements (history, color etc).
Ideally, it shouldn't be possible to have the latter without the
former, but I wouldn't assume that it's completely impossible in
practice.
For now, I think we'll have to be satisfied with distinguishing
between zero elements existing and one or more elements existing,
regardless of the signficance of the elements.
>>> g3dcell MISSING
>> BTW, I'd like to ask again what is the g3dcell?
> No idea.
Could it be removed then?
No idea.
>> Talking of g.remove - could the following types should be disposed in
>> GRASS 7?:
>>
>> 1. sites - there is no sites functionality in Grass>=5.7
>> 2. region3d - 3D region settings have been merged into region
>> 3. 3dview - remainment of Grass <5.7 3d.view command
>> 4? icon - I don't know, propably too? what is it?
>> 5. oldvect
>> 6. asciivect
>>
>> Same applies to g.copy/rename/list
> Removing them from copy/rename seems reasonable enough. However you
> might upgrade from 5.x to 6.x
I'm talking about GRASS 7.
> but still have 5.x entities left in the database directories, so
> you need some way to remove them.
The question might be: is GRASS 7 supposed to provide tools to make the
switch from GRASS 5 easy, like GRASS 6 does?
I see no reason to remove that functionality, given that it's
essentially a few lines in the element_list file. None of this is
actually coded.
--
Glynn Clements <glynn@gclements.plus.com>
I'm surprised more people didn't object at the time; FWIW it's worth I just have trouble with the idea of treating GRASS modules as normal Unix programs that only emit output when there's an error.