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



_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

Michael Barton wrote:

> 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.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Michael Barton]

On 3/24/07 6:21 PM, "Glynn Clements" <[hidden email]> wrote:

>
> Michael Barton wrote:
>
>> 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.

>
> 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



_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

Michael Barton wrote:

> > 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.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[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


On 3/24/07 8:12 PM, "Glynn Clements" <[hidden email]> wrote:

>
> Michael Barton wrote:
>
>>> 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, 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


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[Glynn Clements]

Michael Barton wrote:

> 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.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[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


On 3/25/07 9:41 AM, "Glynn Clements" <[hidden email]> wrote:

>
> Michael Barton wrote:
>
>> 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, 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


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui

[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

2007/3/25, Glynn Clements <[hidden email]>:

>
> Michael Barton wrote:
>
> > 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.
>
> --
> Glynn Clements <[hidden email]>
>
> _______________________________________________
> grassgui mailing list
> [hidden email]
> http://grass.itc.it/mailman/listinfo/grassgui
>

--
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui