[GRASS-windows] r.report, r.patch

[Marco Pasetti]

Hi Helena,

>I have few issues from our class that I would like to ask about winGRASS

First thing: thanks a lot for your feedbacks, I really appreciate your help, 
specially because comes from a high-professional GRASS user ;)
Unfortunaltely I'm very busy in these months (yesterday I passed the first 
PhD entry test), so I cannot partecipate to the project as much I would... 
but the next months will be better...

> 1. r.report does not work for two students (one has VISTA one has XP)
> it does not print anything - it works for me
> and others - has anybody had a similar problem?

No, it's working for me

> 2. r.patch does not work for one student on VISTA-
> it is exactly the same problem reported as bug #118 but
> according to bug tracker it was fixed and closed
> http://trac.osgeo.org/grass/ticket/118
> The command works for me and others on XP. Is there anybody else
> who still has this problem? Michael did your students get it working?

As it has been already discussed, I'm still convinced that for Vista it's 
due to the UAC's presence. About XP, I don't know, r.patch works on my old 
XP machine.

> 3. copy and paste to cmd section of output window makes it copy it twice
> - shift insert works- I have this problem too - is this a feature?

Confirm. I don't know why.

> 4. first one or two letters in output are sometimes skipped  - e.g. min
> is n for r.univar and there are some others. Not a big deal but it is
> somewhat confusing

Yes. I already opened a ticket. It should be fixed in 6.4 trunk, but I don't 
have time to check it out (I should rebuild gdal libs, because I built them 
with GRASS 6.3.0 support for QGIS, and at the moment I need the maximum 
calculus power from my notebook... building on MinGW takes a lot of 
resoruces and time....)

Well... about the differences within different machines running the same OS, 
I cannot tell you what could be the problem. Both XP and Vista are very 
delicate OS, specially XP (because more hackable from users and 3rd party 
applications); lacking or conflicting DLLs, wrong or unusual registry 
setting, anti-viruses or firewall applications may cause unexpected 
problems.
The key should be, in this case, analyze the differences between a working 
setup and the failing ones, and try to identify what may cause the failure. 
It's not a really "scientific" way (it would be nice for a doctor, but not 
for an engineer...), but sometimes it's the smartest way to hit the target.

Thank you very much for your care on the WinGRASS Project,

Marco