[GRASSGUI] initiating d.* command dialogs with existing parameters

[Michael Barton]

I?ve set up a structure (in gisutils and menuform) to pass command
parameters from an existing layer in the GIS Manager to the options dialog
when it is opened. We still need to parse existing d.* command in gismutils
to do this (and of course debug in menuform). This will work much easier if
a command is created as a list instead of a string. Glynn suggested this,
but there were some questions/concerns from Jachym about using spawn. I?ll
hold off on finishing this until we get it settled about parsing a command
as a string or list.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton
I?ve set up a structure (in gisutils and menuform) to pass command
parameters from an existing layer in the GIS Manager to the options dialog
when it is opened. We still need to parse existing d.* command in gismutils
to do this (and of course debug in menuform). This will work much easier if
a command is created as a list instead of a string. Glynn suggested this,
but there were some questions/concerns from Jachym about using spawn. I?ll
hold off on finishing this until we get it settled about parsing a command
as a string or list.

Parsing or passing?

If we're willing to accept a requirement of Python 2.4 or later, then
it appears that the subprocess module (the Popen class and the call
convenience function) is the preferred interface.

It seems to cover all of the required cases, doesn't use a shell
unless explicitly told to, and appears to implement all relevant
functionality on both Unix and Windows.

[Jachym Cepicky]

Hi,

I agree, that Python 2.4 should be the minimum required. I have it on
my laptop too. The "problem" are computers on ITC-irst. We will have
to consult this with system administration..

So from my side: please, continue using python's 2.4 features

Jachym

Post by Michael Barton

Post by Michael Barton
I?ve set up a structure (in gisutils and menuform) to pass command
parameters from an existing layer in the GIS Manager to the options dialog
when it is opened. We still need to parse existing d.* command in

gismutils

Post by Michael Barton
to do this (and of course debug in menuform). This will work much easier

if

Post by Michael Barton
a command is created as a list instead of a string. Glynn suggested this,
but there were some questions/concerns from Jachym about using spawn. I?ll
hold off on finishing this until we get it settled about parsing a command
as a string or list.

Parsing or passing?
If we're willing to accept a requirement of Python 2.4 or later, then
it appears that the subprocess module (the Popen class and the call
convenience function) is the preferred interface.
It seems to cover all of the required cases, doesn't use a shell
unless explicitly told to, and appears to implement all relevant
functionality on both Unix and Windows.
--
_______________________________________________
grassgui mailing list
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

Post by Glynn Clements

Post by Michael Barton
I?ve set up a structure (in gisutils and menuform) to pass command
parameters from an existing layer in the GIS Manager to the options dialog
when it is opened. We still need to parse existing d.* command in gismutils
to do this (and of course debug in menuform). This will work much easier if
a command is created as a list instead of a string. Glynn suggested this,
but there were some questions/concerns from Jachym about using spawn. I?ll
hold off on finishing this until we get it settled about parsing a command
as a string or list.

Parsing or passing?

Both actually. Passing the parameters and parsing them at either end.

Post by Glynn Clements
If we're willing to accept a requirement of Python 2.4 or later, then
it appears that the subprocess module (the Popen class and the call
convenience function) is the preferred interface.
It seems to cover all of the required cases, doesn't use a shell
unless explicitly told to, and appears to implement all relevant
functionality on both Unix and Windows.

I'd tried to use Popen at one point (still commented out) in the command
parser in gismutil.py. I never was able to get it to recognize the PIPE
argument. I probably specified it wrong, but I could never find out how to
get it right.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton

Post by Glynn Clements
If we're willing to accept a requirement of Python 2.4 or later, then
it appears that the subprocess module (the Popen class and the call
convenience function) is the preferred interface.
It seems to cover all of the required cases, doesn't use a shell
unless explicitly told to, and appears to implement all relevant
functionality on both Unix and Windows.

I'd tried to use Popen at one point (still commented out) in the command
parser in gismutil.py. I never was able to get it to recognize the PIPE
argument. I probably specified it wrong, but I could never find out how to
get it right.

What do you mean by "recognize"?

The call looks okay, except that

self.out = subprocess.Popen(cmd, shell=True, stdout=PIPE).stdout

is assigning a stream to self.out while the existing call:

self.out = os.popen(cmd, "r").read()

is assigning a string. The former will cause the line:

self.cmd_output.write(self.out+"\n")

to fail, as self.out won't be a string.

[Michael Barton]

I can't remember the exact error, but it said essentially that "PIPE" is not
a valid parameter. This could be a bug in the Mac version, of course. But it
would be nice to see if it works on another platform before I report it, in
case I've just forgotten some punctuation, capitalization, or something.

Michael

Post by Glynn Clements

Post by Michael Barton

Post by Glynn Clements
If we're willing to accept a requirement of Python 2.4 or later, then
it appears that the subprocess module (the Popen class and the call
convenience function) is the preferred interface.
It seems to cover all of the required cases, doesn't use a shell
unless explicitly told to, and appears to implement all relevant
functionality on both Unix and Windows.

I'd tried to use Popen at one point (still commented out) in the command
parser in gismutil.py. I never was able to get it to recognize the PIPE
argument. I probably specified it wrong, but I could never find out how to
get it right.

What do you mean by "recognize"?
The call looks okay, except that
self.out = subprocess.Popen(cmd, shell=True, stdout=PIPE).stdout
self.out = os.popen(cmd, "r").read()
self.cmd_output.write(self.out+"\n")
to fail, as self.out won't be a string.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton
I can't remember the exact error, but it said essentially that "PIPE" is not
a valid parameter. This could be a bug in the Mac version, of course. But it
would be nice to see if it works on another platform before I report it, in
case I've just forgotten some punctuation, capitalization, or something.

You either need to use subprocess.PIPE, or change "import subprocess"
to "from subprocess import *". If you take the latter approach, you
need to remove the "subprocess." prefix from subprocess.call,
subprocess.Popen etc.

The "import <module>" syntax requires you to use qualified names,
while "from <module> import *" allows you to use unqualified names.

Alternatively, you can import specific identifiers, e.g.:

from subprocess import (call, Popen, PIPE, STDOUT)

In any case, the call:

self.out = Popen(cmd, shell=True, stdout=PIPE, stderr=STDOUT).communicate()[0]

seems to work once the relevant identifiers have been imported.

BTW, GMConsole.runCmd() currently executes the command twice; once
with call(), and again with os.popen().

Also, I had to remove an "import images" statement from wxgui.py; that
module doesn't appear to exist.

[Michael Barton]

Thanks much for the advice on how to make this work properly. Sorry about
the images. I forgot to take that out. I'd added that so that I could test
code from the wxPython demo--to try and debug something.

Michael

Post by Glynn Clements

Post by Michael Barton
I can't remember the exact error, but it said essentially that "PIPE" is not
a valid parameter. This could be a bug in the Mac version, of course. But it
would be nice to see if it works on another platform before I report it, in
case I've just forgotten some punctuation, capitalization, or something.

You either need to use subprocess.PIPE, or change "import subprocess"
to "from subprocess import *". If you take the latter approach, you
need to remove the "subprocess." prefix from subprocess.call,
subprocess.Popen etc.
The "import <module>" syntax requires you to use qualified names,
while "from <module> import *" allows you to use unqualified names.
from subprocess import (call, Popen, PIPE, STDOUT)
self.out = Popen(cmd, shell=True, stdout=PIPE,
stderr=STDOUT).communicate()[0]
seems to work once the relevant identifiers have been imported.
BTW, GMConsole.runCmd() currently executes the command twice; once
with call(), and again with os.popen().
Also, I had to remove an "import images" statement from wxgui.py; that
module doesn't appear to exist.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton