[GRASS5] Re: [GRASSLIST:8545] Re: d.m - commands output pollute the Grass terminal

GRASS GIS GRASS GIS developer
1

Following up on a suggestion by Maciek and information by Glynn, I've played
around with outputting GIS Manager commands to a separate terminal window a
bit.

Currently, all GIS Manager commands send their output to the GRASS terminal
so that the relevant display commands are echoed there (using TclTk "puts"
for each command).

However, the GIS Manager can be started in a separate xterm where all
command output will be displayed, keeping the main GRASS xterm free of this
output and cleaner looking. The drawback is that it opens another window on
the screen.

The simplest way to do this seems to be in modifying the d.m script that
starts the GIS Manager. Because it's a very small file, I've attached a
suggested way to do this here. (I've kept the original lines and commented
them out).

To keep the GIS Manager command output xterm visually distinct from the main
GRASS xterm (and any other xterm), I've given it a descriptive window name,
colored it in the new GIS Manager color that Hamish suggested, made it a bit
smaller, and placed it in the upper right hand corner.

If you folks think this is an improvement, I can add it to the CVS on Monday
(or one of you can add it over the weekend).

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Glynn Clements <glynn@gclements.plus.com>
Date: Sat, 08 Oct 2005 10:29:22 +0100
To: Michael Barton <michael.barton@asu.edu>
Cc: Maciek Sieczka <werchowyna@epf.pl>, <grasslist@baylor.edu>
Subject: Re: [GRASSLIST:8545] Re: d.m - commands output pollute the Grass
terminal

Michael Barton wrote:

I understand, that's good. But could there be a permanent, *separate*
terminal for output from d.m commands? It could be the small, neat one - the
same which pops up when we query raster layers from d.m.

Currently my Grass terminal looks like a Matrix screesaver when I redraw 20
layers in d.m. Main terminal should be for CLI, GUI should have a separate
text output, I guess.

This is a good idea but I don't know how to redirect this output to a
separate terminal. Anyone have a suggestion?

xterm -e d.m &

or, if xterm is setuid:

xterm -e $GISBASE/etc/grass-run.sh d.m &

--
Glynn Clements <glynn@gclements.plus.com>

(attachments)

d.m (745 Bytes)

2

On Sun, October 9, 2005 07:47, Michael Barton wrote:

Following up on a suggestion by Maciek and information by Glynn, I've played
around with outputting GIS Manager commands to a separate terminal window a
bit.

Currently, all GIS Manager commands send their output to the GRASS terminal
so that the relevant display commands are echoed there (using TclTk "puts"
for each command).

However, the GIS Manager can be started in a separate xterm where all
command output will be displayed, keeping the main GRASS xterm free of this
output and cleaner looking. The drawback is that it opens another window on
the screen.

Yes, and I find that quite a strong drawback, as GRASS already opens quite a
lot of windows. Couldn't the GIS Manager output just be logged to a file, thus
making the output available to those who really need it without cluttering
terminal or screen ?

Moritz

3

Michael Barton wrote:

Following up on a suggestion by Maciek and information by Glynn, I've played
around with outputting GIS Manager commands to a separate terminal window a
bit.

Currently, all GIS Manager commands send their output to the GRASS terminal
so that the relevant display commands are echoed there (using TclTk "puts"
for each command).

In the version I have here, only Dm::execute does that, which is only
used by print.tcl.

Dm::execute takes the command as a string, which won't work for
non-trivial commands (e.g. those where arguments contain spaces or
shell metacharacters).

--
Glynn Clements <glynn@gclements.plus.com>

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glynn Clements wrote:

Michael Barton wrote:

Following up on a suggestion by Maciek and information by Glynn, I've played
around with outputting GIS Manager commands to a separate terminal window a
bit.

Currently, all GIS Manager commands send their output to the GRASS terminal
so that the relevant display commands are echoed there (using TclTk "puts"
for each command).

In the version I have here, only Dm::execute does that, which is only
used by print.tcl.

Dm::execute takes the command as a string, which won't work for
non-trivial commands (e.g. those where arguments contain spaces or
shell metacharacters).

I can confirm that. Simple copy-and-paste won't work in those cases.

As a side remark, this might be an argument for avoiding arguments
with spaces whenever possible. For example, in d.vect.thematique, it
might be better to find other names for arguments such as 'graduated
colors', 'custom gradient', 'standard deviation', etc.

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDSRm7rIrMbm76jD8RAhnZAJ9KHqqSQ2iuWDWCDc1KjP3frrzAegCbBH4W
+BFRaXbyzKaCOF0uNs1fwVY=
=Eovv
-----END PGP SIGNATURE-----

5

Moritz Lennert wrote:

>>Following up on a suggestion by Maciek and information by Glynn, I've played
>>around with outputting GIS Manager commands to a separate terminal window a
>>bit.
>>
>>Currently, all GIS Manager commands send their output to the GRASS terminal
>>so that the relevant display commands are echoed there (using TclTk "puts"
>>for each command).
>
>
> In the version I have here, only Dm::execute does that, which is only
> used by print.tcl.
>
> Dm::execute takes the command as a string, which won't work for
> non-trivial commands (e.g. those where arguments contain spaces or
> shell metacharacters).
>

I can confirm that. Simple copy-and-paste won't work in those cases.

As a side remark, this might be an argument for avoiding arguments
with spaces whenever possible. For example, in d.vect.thematique, it
might be better to find other names for arguments such as 'graduated
colors', 'custom gradient', 'standard deviation', etc.

No need. Tcl has perfectly good support for lists; there's no reason
to treat a command as a string.

--
Glynn Clements <glynn@gclements.plus.com>

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glynn Clements wrote:

Moritz Lennert wrote:

As a side remark, this might be an argument for avoiding arguments
with spaces whenever possible. For example, in d.vect.thematique, it
might be better to find other names for arguments such as 'graduated
colors', 'custom gradient', 'standard deviation', etc.

No need. Tcl has perfectly good support for lists; there's no reason
to treat a command as a string.

Well, my remark was meant for the command line, where you have to
know that you have to put some of the options between quotes because
there are spaces between them. I just think it would make life
easier for everyone if we avoid option names with spaces in them...

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDShuKrIrMbm76jD8RAngqAJ4ho6Mku14ScnpLe7GZv6MuhsYXTACfV4TA
auyCnNehshtvezUhprKr+cY=
=vz4d
-----END PGP SIGNATURE-----

7

Moritz,

This makes sense. When I originally wrote the script, I was thinking of
making the options understandable, and didn't really anticipate how much
more complex and useful it would become. When I was porting it to a GIS
Manager panel, I toyed with the idea of changing the options to single words
but didn't at that point because it seems to have become very widely used
and I didn't want to cause existing users a lot of grief.

I think it would be better to rename some of these options, but I'm not sure
of the smoothest way to transition everyone to new single word names. Do any
of you have experience with this?

Michael
______________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Mon, 10 Oct 2005 09:43:06 +0200
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Michael Barton <michael.barton@asu.edu>, grass5 developers list
<grass5@grass.itc.it>
Subject: Re: [GRASS5] Re: [GRASSLIST:8545] Re: d.m - commands output pollute
the Grass terminal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glynn Clements wrote:

Moritz Lennert wrote:

As a side remark, this might be an argument for avoiding arguments
with spaces whenever possible. For example, in d.vect.thematique, it
might be better to find other names for arguments such as 'graduated
colors', 'custom gradient', 'standard deviation', etc.

No need. Tcl has perfectly good support for lists; there's no reason
to treat a command as a string.

Well, my remark was meant for the command line, where you have to
know that you have to put some of the options between quotes because
there are spaces between them. I just think it would make life
easier for everyone if we avoid option names with spaces in them...

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDShuKrIrMbm76jD8RAngqAJ4ho6Mku14ScnpLe7GZv6MuhsYXTACfV4TA
auyCnNehshtvezUhprKr+cY=
=vz4d
-----END PGP SIGNATURE-----

8

>>> As a side remark, this might be an argument for avoiding arguments
>>> with spaces whenever possible. For example, in d.vect.thematique,
>>> it might be better to find other names for arguments such as
>>> 'graduated colors', 'custom gradient', 'standard deviation', etc.
>>
>> No need. Tcl has perfectly good support for lists; there's no
>> reason to treat a command as a string.
>>
>
> Well, my remark was meant for the command line, where you have to
> know that you have to put some of the options between quotes because
> there are spaces between them. I just think it would make life
> easier for everyone if we avoid option names with spaces in them...

This makes sense. When I originally wrote the script, I was thinking
of making the options understandable, and didn't really anticipate how
much more complex and useful it would become. When I was porting it to
a GIS Manager panel, I toyed with the idea of changing the options to
single words but didn't at that point because it seems to have become
very widely used and I didn't want to cause existing users a lot of
grief.

I think it would be better to rename some of these options, but I'm
not sure of the smoothest way to transition everyone to new single
word names. Do any of you have experience with this?

Just replace the spaces with underscores. As long as the module wasn't
included in the 6.0.x releases I don't think there is a problem fine-
tuning the development version. It's not supposed to be stable; the
possibility of bugs and change is the price you pay for getting access
to the latest & greatest. I for one agree that fixed module options
should not contain spaces.

Hamish

9

OK. I guess I'll make this change when I update d.vect.thematic to do
variable width lines.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Hamish <hamish_nospam@yahoo.com>
Date: Tue, 11 Oct 2005 17:15:37 +1300
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass5@grass.itc.it>
Subject: Re: [GRASS5] Re: [GRASSLIST:8545] Re: d.vect.thematic options with
spaces

As a side remark, this might be an argument for avoiding arguments
with spaces whenever possible. For example, in d.vect.thematique,
it might be better to find other names for arguments such as
'graduated colors', 'custom gradient', 'standard deviation', etc.

No need. Tcl has perfectly good support for lists; there's no
reason to treat a command as a string.

Well, my remark was meant for the command line, where you have to
know that you have to put some of the options between quotes because
there are spaces between them. I just think it would make life
easier for everyone if we avoid option names with spaces in them...

This makes sense. When I originally wrote the script, I was thinking
of making the options understandable, and didn't really anticipate how
much more complex and useful it would become. When I was porting it to
a GIS Manager panel, I toyed with the idea of changing the options to
single words but didn't at that point because it seems to have become
very widely used and I didn't want to cause existing users a lot of
grief.

I think it would be better to rename some of these options, but I'm
not sure of the smoothest way to transition everyone to new single
word names. Do any of you have experience with this?

Just replace the spaces with underscores. As long as the module wasn't
included in the 6.0.x releases I don't think there is a problem fine-
tuning the development version. It's not supposed to be stable; the
possibility of bugs and change is the price you pay for getting access
to the latest & greatest. I for one agree that fixed module options
should not contain spaces.

Hamish

10

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Barton wrote:

Moritz,

This makes sense. When I originally wrote the script, I was thinking of
making the options understandable, and didn't really anticipate how much
more complex and useful it would become. When I was porting it to a GIS
Manager panel, I toyed with the idea of changing the options to single words
but didn't at that point because it seems to have become very widely used
and I didn't want to cause existing users a lot of grief.

I think it would be better to rename some of these options, but I'm not sure
of the smoothest way to transition everyone to new single word names. Do any
of you have experience with this?

What you could do is just check for two possible names, i.e. when you do

case "$GIS_OPT_themecalc" in

check for "standard deviation" and "std" (or another one word form).

If you do not mention the possibility of using space separated
options in the --help info and the man page, then sooner or later
people will stop using it, I guess (but legacy code could continue
to function).

Just an idea...

Moritz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDS4BtrIrMbm76jD8RAj4KAJ4/wpyF2dTI+OUot9dL/pTC+080ZwCeK/pQ
iqW1OEyM678H37oL6v3M9cE=
=EC8r
-----END PGP SIGNATURE-----

11

Moritz Lennert wrote:

>>As a side remark, this might be an argument for avoiding arguments
>>with spaces whenever possible. For example, in d.vect.thematique, it
>>might be better to find other names for arguments such as 'graduated
>>colors', 'custom gradient', 'standard deviation', etc.
>
>
> No need. Tcl has perfectly good support for lists; there's no reason
> to treat a command as a string.
>

Well, my remark was meant for the command line, where you have to
know that you have to put some of the options between quotes because
there are spaces between them. I just think it would make life
easier for everyone if we avoid option names with spaces in them...

Some commands will have spaces in the argument values, e.g. r.mapcalc.

It's far more robust to simply ensure that the code correctly handles
arguments which contain spaces (or other metacharacters).

Tcl's exec command takes each word of the command as a separate
function argument (a word is a program, argument, redirection
specifier etc).

Similarly, when the first character in the first argument to Tcl's
open command is a "|" symbol, the remainder of the argument is treated
as a Tcl list where each element is one word of the command.

Constructing a valid command from variables simply means using e.g.:

  set cmd [list $foo $bar]

rather than:

  set cmd "$foo $bar"

as the former will insert braces as requireed to preserve list
structure.

--
Glynn Clements <glynn@gclements.plus.com>