On Aug 1, 2004, at 10:01 PM, Multiple recipients of list wrote:
Hi
I'm not sure if the developers of GRASS read this list; if not, forgive me for being off-topic.
One observation:
One thing I miss in the new GUI of GRASS 5.7 that I have in GRASS 5.03: The little blue text saying "Running..." and "Finished". It was really usefull and now it is sometimes difficult to know if a command is still busy or has already finished. (This is especially true for a newbie when I have no idea how long a command would normally run at different resolutions).
This is something generated (or not) within each command module. Some of them have it in GRASS 5.7. Most of the scripts I've written or updated from GRASS 5.3 to 5.7 print a message when they are done. Sometimes it doesn't really matter and other times it is very helpful. What is most annoying to me are those older commands that send an email message when they are completed. Of course these go to an internal mail system and never reaches the email I normally look at. Periodically I look up how to get these messages. Then, because I rarely use this, I promptly forget it.
One question:
It seems to me that (at least some) commands on the CLI differs a bit from those on the GUI. Was this a deliberate decision? If so, why?
This is indeed the case...sometimes. In most cases, it is due to a problem with the module that automatically generates and read the GUI dialogs in GRASS 5.7. All the dialogs that pop up when you type a command or select it from the menu are automatically generated for each command. You can even have a dialog automatically generated for a script that you write. Look at the documentation for g.parser or some of the scripts that come with GRASS 5.7 to get some idea of how it works. It is actually quite slick and gives GRASS 5.7 a much better interface much easier than before. However, this version is still in development and there are a few glitches. IMHO, the biggest one interface-wise at present is that the parsing program that generates and reads these autogenerated dialogs has trouble with entries that contain spaces. This causes a variety of things to not work quite right when you use the GUI. SQL queries are the most notable perhaps. You can specify [variable='foo'] but not [variable='foo' or variable='faa']. This DOES work just fine from the command line. Currently, I'd guess about 90% or more of the commands work just fine from the GUI. Of the remaining ones, most work OK for most options, and choke on a few others. Developers are trying to fix this issue.
Michael
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
What is most annoying to me are those older commands that send an email
message when they are completed. Of course these go to an internal mail
system and never reaches the email I normally look at. Periodically I
look up how to get these messages. Then, because I rarely use this, I
promptly forget it.
A couple of points:
1. If one of the files ~/GIS_ERROR_LOG or $GISBASE/GIS_ERROR_LOG
exists and is writable, any error messages will be written to that
file.
2. If the environment variable GRASS_STDERR is set, error messages
will not be emailed.
Thanks for the information on error messages. Some commands also indicate
that they have completed their processing by sending an email (r.proj for
example). I *think* (but am not sure) that this goes to sendmail. Since I
now have postfix internally--but only use it in some circumstances for its
smtp server--I'm not sure where this ends up.
Michael
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
From: Glynn Clements <glynn.clements@virgin.net>
Date: Tue, 03 Aug 2004 00:26:16 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Multiple recipients of list <GRASSLIST@baylor.edu>
Subject: Re: [GRASSLIST:4063] GRASS5.03 vs GRASS5.7
Michael Barton wrote:
What is most annoying to me are those older commands that send an email
message when they are completed. Of course these go to an internal mail
system and never reaches the email I normally look at. Periodically I
look up how to get these messages. Then, because I rarely use this, I
promptly forget it.
A couple of points:
1. If one of the files ~/GIS_ERROR_LOG or $GISBASE/GIS_ERROR_LOG
exists and is writable, any error messages will be written to that
file.
2. If the environment variable GRASS_STDERR is set, error messages
will not be emailed.
Thanks for the information on error messages. Some commands also indicate
that they have completed their processing by sending an email (r.proj for
example).
r.proj doesn't do this. Are you thinking of photo.rectify (part of
i.ortho.photo)? That sends mail upon completion. But then the imagery
stuff never was particularly well integrated with the rest of GRASS.
I *think* (but am not sure) that this goes to sendmail. Since I
now have postfix internally--but only use it in some circumstances for its
smtp server--I'm not sure where this ends up.
photo.rectify and the libgis error-handling code both use the "mail"
program to send notification messages; e.g. (from photo.rectify):
mail = popen ("mail `whoami`","w");
The mail will end up wherever the "mail" program (assuming that you
have one) sends it, based upon the username returned by "whoami"
(whoami returns the username from /etc/passwd corresponding to the
effective UID).
For a traditional Unix mail program, it will probably go to
/usr/lib/sendmail or /usr/sbin/sendmail (which may or may not be the
"actual" sendmail program; most MTAs include a program/script named
"sendmail" for compatibility purposes).
FWIW, this is essentially the same mechanism used by daemons which
send email, e.g. crond.
Needless to say, this is all somewhat Unix-specific. If you aren't
using a "conventional" Unix system (e.g. you don't have a "mail"
program or an appropriate entry in /etc/passwd), it may not work.
Just to chime in, on my mac running OS 10.3.4, my mail is sent to /var/mail/my_user_name. I also get a message sent to my terminal window whenever I have new mail. This is a new feature for me, but I am not sure if it has to do with a change from OS 10.2 to 10.3 or from OroborOSX to Apple's X11 or from grass 5.0.0 to 5.3/5.7 (I certainly didn't conciously change anything else). Regardless, the mail function now at least serves some purpose for me. Thanks to whomever.
-Ian
On Aug 2, 2004, at 11:13 PM, Glynn Clements wrote:
Michael Barton wrote:
Thanks for the information on error messages. Some commands also indicate
that they have completed their processing by sending an email (r.proj for
example).
r.proj doesn't do this. Are you thinking of photo.rectify (part of
i.ortho.photo)? That sends mail upon completion. But then the imagery
stuff never was particularly well integrated with the rest of GRASS.
I *think* (but am not sure) that this goes to sendmail. Since I
now have postfix internally--but only use it in some circumstances for its
smtp server--I'm not sure where this ends up.
photo.rectify and the libgis error-handling code both use the "mail"
program to send notification messages; e.g. (from photo.rectify):
mail = popen ("mail `whoami`","w");
The mail will end up wherever the "mail" program (assuming that you
have one) sends it, based upon the username returned by "whoami"
(whoami returns the username from /etc/passwd corresponding to the
effective UID).
For a traditional Unix mail program, it will probably go to
/usr/lib/sendmail or /usr/sbin/sendmail (which may or may not be the
"actual" sendmail program; most MTAs include a program/script named
"sendmail" for compatibility purposes).
FWIW, this is essentially the same mechanism used by daemons which
send email, e.g. crond.
Needless to say, this is all somewhat Unix-specific. If you aren't
using a "conventional" Unix system (e.g. you don't have a "mail"
program or an appropriate entry in /etc/passwd), it may not work.
Thanks for the information on error messages. Some commands also indicate
that they have completed their processing by sending an email (r.proj for
example). I *think* (but am not sure) that this goes to sendmail. Since I
now have postfix internally--but only use it in some circumstances for its
smtp server--I'm not sure where this ends up.
I use postfix and it works perfectly with GRASS and e.g. i.rectify. It is desinged to be a drop-in replacement for sendmail.
Is there any way to set this module up so that we can compile it without
having to compile all of GRASS 5.7? This would be useful for other modules
also. Perhaps it is impossible as it uses to much general GRASS source code.
But if not, this would be nice.
Michael
On 8/25/04 5:02 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
How can i import an dxf file in grass 5.7, i was trying but i
didn't find it in the gui. ¿console?
You need to compile GRASS with DWG support and use v.in.dwg.
This requires downloading a library from the internet which you can not
redistribute.
____________________
C. Michael Barton, Professor
School of Human Diversity and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA