[GRASS-user] Problems with GRASS python code in osgeo4w

[bmoskovi]

Hello List,

I’m trying to figure out how to write python scripts using grass.py under osgeo4w. I was hoping that python script (and the binary commands) would behave similarly to the grass environment on my Ubuntu box. You know…just type the command and the gui for that command comes up. What I have to do now is type “python c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py” instead of just type “m.dipslope.py”. I’ve also notice that the command gui or even the command help does not come up when you just enter the command. Ultimately I would like to put my commands in the QGIS GRASS module tree.

Bob Moskovitz
Research Analyst I
Seismic Hazard Zonation Project
California Geological Survey
http://www.conservation.ca.gov/cgs/shzp

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed. This message contains information from the State of California, California Geological Survey, which may be privileged, confidential and exempt from disclosure under applicable law, including the Electronic Communications Privacy Act. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.

[Glynn_Clements1]

Moskovitz, Bob wrote:

I'm trying to figure out how to write python scripts using grass.py
under osgeo4w. I was hoping that python script (and the binary
commands) would behave similarly to the grass environment on my Ubuntu
box. You know...just type the command and the gui for that command
comes up. What I have to do now is type "python
c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py" instead of
just type "m.dipslope.py". I've also notice that the command gui or
even the command help does not come up when you just enter the command.
Ultimately I would like to put my commands in the QGIS GRASS module
tree.

1. Ensure that .py files are configured to be run with the Python
interpreter. You should be able to double-click on a .py file in
Explorer and have it run. This should be done by the Python installer,
but I don't know if the OSGeo4W installer does this.

If it isn't, you can use e.g.:

  assoc .py=python.file
  ftype python.file="C:\Program Files\Python25\python.exe" "%1"

[Change the pathname to wherever Python is installed.]

2. The PATHEXT environment variable needs to contain ".PY" if you want
to use "m.dispslope" rather than "m.dispslope.py". You can do this
temporarily with:

  set PATHEXT=%PATHEXT%;.PY

or you can make it persistent either using the Control Panel or
through the registry.

For the Control Panel in XP, it's:

My Computer
Control Panel
  System
   Advanced (Tab)
    Environment Variables

For the registry, the system-wide setting is taken from the PATHEXT
value of the key:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Or you can override it for the current user by adding a PATHEXT value
to the key HKCU\Environment

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

[bmoskovi]

Thanks for the info. I didn't know about the assoc and ftype. Looking at the output of these two commands, I see that my system is set up correctly.

So, I still don't know why the grass.parser() is not working for me. I even modified my program to use pdb to see what is happening. The debugger is aborted right after I reach os.execvp("g.parser.exe", [name] + argv) in grass.py. But if I use "python c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help", I get the expected results.

Bob Moskovitz
Research Analyst I
Seismic Hazard Evaluation Project
California Geological Survey
http://gmw.consrv.ca.gov/shmp

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed. This message contains information from the State of California, California Geological Survey, which may be privileged, confidential and exempt from disclosure under applicable law, including the Electronic Communications Privacy Act. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.

-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Friday, June 19, 2009 7:03 PM
To: Moskovitz, Bob
Cc: Grass-User (E-mail)
Subject: Re: [GRASS-user] Problems with GRASS python code in osgeo4w

Moskovitz, Bob wrote:

> I'm trying to figure out how to write python scripts using grass.py
> under osgeo4w. I was hoping that python script (and the binary
> commands) would behave similarly to the grass environment
on my Ubuntu
> box. You know...just type the command and the gui for that command
> comes up. What I have to do now is type "python
> c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py"
instead of
> just type "m.dipslope.py". I've also notice that the command gui or
> even the command help does not come up when you just enter
the command.
> Ultimately I would like to put my commands in the QGIS GRASS module
> tree.

1. Ensure that .py files are configured to be run with the Python
interpreter. You should be able to double-click on a .py file in
Explorer and have it run. This should be done by the Python installer,
but I don't know if the OSGeo4W installer does this.

If it isn't, you can use e.g.:

  assoc .py=python.file
  ftype python.file="C:\Program Files\Python25\python.exe" "%1"

[Change the pathname to wherever Python is installed.]

2. The PATHEXT environment variable needs to contain ".PY" if you want
to use "m.dispslope" rather than "m.dispslope.py". You can do this
temporarily with:

  set PATHEXT=%PATHEXT%;.PY

or you can make it persistent either using the Control Panel or
through the registry.

For the Control Panel in XP, it's:

My Computer
Control Panel
  System
   Advanced (Tab)
    Environment Variables

For the registry, the system-wide setting is taken from the PATHEXT
value of the key:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Or you can override it for the current user by adding a PATHEXT value
to the key HKCU\Environment

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

[Glynn_Clements1]

Moskovitz, Bob wrote:

Thanks for the info. I didn't know about the assoc and ftype. Looking
at the output of these two commands, I see that my system is set up
correctly.

So, I still don't know why the grass.parser() is not working for me. I
even modified my program to use pdb to see what is happening. The
debugger is aborted right after I reach os.execvp("g.parser.exe", [name]
+ argv) in grass.py. But if I use "python
c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help", I
get the expected results.

Does it work if you run the script using its full path, i.e.:

c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help

?

You could try modifying etc/python/grass/script/core.py to print the
arguments which are passed to g.parser.

The code attempts to determine the script's full pathname, as g.parser
needs this so that it can open the script to read the #% comments
(PATH won't help here).

It appears that this part is where the problem lies. If the script is
run with --help or --ui, g.parser doesn't get around to re-invoking
the script, so that isn't an issue.

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

[bmoskovi]

There is no etc/python/grass/script/core.py. Just etc\python\grass.py. Here is a part of a pdb debug session:

c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()

-> if sys.platform == "win32":
(Pdb)

c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()

-> try:
(Pdb)

c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()

-> os.execvp("g.parser.exe", [name] + argv)
(Pdb) p [name] + argv
['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py', 'c:\\osgeo
4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
(Pdb)

-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Monday, June 22, 2009 3:30 PM
To: Moskovitz, Bob
Cc: Grass-User (E-mail)
Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w

Moskovitz, Bob wrote:

> Thanks for the info. I didn't know about the assoc and
ftype. Looking
> at the output of these two commands, I see that my system is set up
> correctly.
>
> So, I still don't know why the grass.parser() is not
working for me. I
> even modified my program to use pdb to see what is happening. The
> debugger is aborted right after I reach
os.execvp("g.parser.exe", [name]
> + argv) in grass.py. But if I use "python
> c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py
--help", I
> get the expected results.

Does it work if you run the script using its full path, i.e.:

c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help

?

You could try modifying etc/python/grass/script/core.py to print the
arguments which are passed to g.parser.

The code attempts to determine the script's full pathname, as g.parser
needs this so that it can open the script to read the #% comments
(PATH won't help here).

It appears that this part is where the problem lies. If the script is
run with --help or --ui, g.parser doesn't get around to re-invoking
the script, so that isn't an issue.

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

[bmoskovi]

I also wanted to add that I did run the program like this: c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help

-----Original Message-----
From: grass-user-bounces@lists.osgeo.org
[mailto:grass-user-bounces@lists.osgeo.org]On Behalf Of Moskovitz, Bob
Sent: Monday, June 22, 2009 4:07 PM
To: Glynn Clements
Cc: Grass-User (E-mail)
Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w

There is no etc/python/grass/script/core.py. Just
etc\python\grass.py. Here is a part of a pdb debug session:

> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()
-> if sys.platform == "win32":
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
-> try:
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
-> os.execvp("g.parser.exe", [name] + argv)
(Pdb) p [name] + argv
['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslop
e.py', 'c:\\osgeo
4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
(Pdb)

[bmoskovi]

I debugged a bit deeper with pdb and found this:
(Pdb)

c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()

-> os.execvp("g.parser.exe", [name] + argv)
(Pdb) s
==================== snip ===============================================

c:\warmerda\release\apps\python25\lib\os.py(389)_execvpe()

-> func(fullname, *argrest)
(Pdb) p fullname
'c:\\osgeo4w\\bin\\g.parser.exe'
(Pdb) PATH
['c:\\osgeo4w\\bin', 'C:\\OSGeo4W/apps/grass/grass-6.4.0svn\\bin', 'C:\\OSGeo4W/
apps/grass/grass-6.4.0svn\\lib', 'C:\\OSGeo4W\\bin', 'C:\\Perl\\bin\\', 'C:\\WIN
DOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem', 'C:\\Perl\\bin\\'
,'C:\\WINDOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem']

There is no c:\osgeo4w\bin\g.parser.exe but there is a C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\g.parser.exe.

-----Original Message-----
From: Moskovitz, Bob
Sent: Monday, June 22, 2009 4:17 PM
To: Moskovitz, Bob; Glynn Clements
Cc: Grass-User (E-mail)
Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w

I also wanted to add that I did run the program like this:
c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts\m.dipslope.py --help

> -----Original Message-----
> From: grass-user-bounces@lists.osgeo.org
> [mailto:grass-user-bounces@lists.osgeo.org]On Behalf Of
Moskovitz, Bob
> Sent: Monday, June 22, 2009 4:07 PM
> To: Glynn Clements
> Cc: Grass-User (E-mail)
> Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w
>
>
> There is no etc/python/grass/script/core.py. Just
> etc\python\grass.py. Here is a part of a pdb debug session:
>
> >
c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()
> -> if sys.platform == "win32":
> (Pdb)
> >
c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
> -> try:
> (Pdb)
> >
c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
> -> os.execvp("g.parser.exe", [name] + argv)
> (Pdb) p [name] + argv
> ['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslop
> e.py', 'c:\\osgeo
> 4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
> (Pdb)
>
>

[Glynn_Clements1]

Moskovitz, Bob wrote:

There is no etc/python/grass/script/core.py. Just
etc\python\grass.py.

That changed in the last month or so, but I don't think that it has
any bearing on this.

Here is a part of a pdb debug session:

> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()

I don't like the look of the "grass-~1.0sv" bit.

-> if sys.platform == "win32":
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
-> try:
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
-> os.execvp("g.parser.exe", [name] + argv)
(Pdb) p [name] + argv
['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py', 'c:\\osgeo
4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
(Pdb)

That much looks okay.

I debugged a bit deeper with pdb and found this:
(Pdb)
> c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
-> os.execvp("g.parser.exe", [name] + argv)
(Pdb) s
==================== snip ===============================================
> c:\warmerda\release\apps\python25\lib\os.py(389)_execvpe()
-> func(fullname, *argrest)
(Pdb) p fullname
'c:\\osgeo4w\\bin\\g.parser.exe'
(Pdb) PATH
['c:\\osgeo4w\\bin', 'C:\\OSGeo4W/apps/grass/grass-6.4.0svn\\bin', 'C:\\OSGeo4W/
apps/grass/grass-6.4.0svn\\lib', 'C:\\OSGeo4W\\bin', 'C:\\Perl\\bin\\', 'C:\\WIN
DOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem', 'C:\\Perl\\bin\\'
,'C:\\WINDOWS\\system32', 'C:\\WINDOWS', 'C:\\WINDOWS\\System32\\Wbem']

There is no c:\osgeo4w\bin\g.parser.exe but there is a C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\g.parser.exe.

This is a red herring. os.execvp() iterates through PATH, attempting
each directory in turn until it succeeds.

However, the fact that the GRASS bin and lib directories have forward
slashes might be a problem. Try correcting PATH from the command line
first.

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

[bmoskovi]

I noticed that most of the *.bat files have forward slashes. For example:

C:\OSGeo4W\apps\grass\bin\grass64.bat: set WINGISBASE=/c/OSGeo4W/apps/grass/grass-6.4.0RC4
C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\d.correlate.bat: @"%GRASS_SH%" -c '"%GISBASE%/scripts/d.correlate" %*'
C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\Init.bat: if "%GRASS_PROJSHARE%"=="" set GRASS_PROJSHARE=/c/OSGeo4W/share/proj
C:\OSGeo4W\bin\grass64.bat set WINGISBASE=%OSGEO4W_ROOT%/apps/grass/grass-6.4.0svn

Why is there 2 grass64.bat?

Bob Moskovitz
Research Analyst I
Seismic Hazard Evaluation Project
California Geological Survey
http://gmw.consrv.ca.gov/shmp

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed. This message contains information from the State of California, California Geological Survey, which may be privileged, confidential and exempt from disclosure under applicable law, including the Electronic Communications Privacy Act. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.

-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Monday, June 22, 2009 7:22 PM
To: Moskovitz, Bob
Cc: Grass-User (E-mail)
Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w

Moskovitz, Bob wrote:

> There is no etc/python/grass/script/core.py. Just
> etc\python\grass.py.

That changed in the last month or so, but I don't think that it has
any bearing on this.

> Here is a part of a pdb debug session:
>
> >
c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(208)parser()

I don't like the look of the "grass-~1.0sv" bit.

> -> if sys.platform == "win32":
> (Pdb)
> >
c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(209)parser()
> -> try:
> (Pdb)
> >
c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
> -> os.execvp("g.parser.exe", [name] + argv)
> (Pdb) p [name] + argv
>
['c:\\osgeo4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslop
e.py', 'c:\\osgeo
> 4w\\apps\\grass\\grass-6.4.0svn\\scripts\\m.dipslope.py']
> (Pdb)

That much looks okay.

> I debugged a bit deeper with pdb and found this:
> (Pdb)
> >
c:\osgeo4w\apps\grass\grass-~1.0sv\etc\python\grass.py(210)parser()
> -> os.execvp("g.parser.exe", [name] + argv)
> (Pdb) s
> ==================== snip

> > c:\warmerda\release\apps\python25\lib\os.py(389)_execvpe()
> -> func(fullname, *argrest)
> (Pdb) p fullname
> 'c:\\osgeo4w\\bin\\g.parser.exe'
> (Pdb) PATH
> ['c:\\osgeo4w\\bin',
'C:\\OSGeo4W/apps/grass/grass-6.4.0svn\\bin', 'C:\\OSGeo4W/
> apps/grass/grass-6.4.0svn\\lib', 'C:\\OSGeo4W\\bin',
'C:\\Perl\\bin\\', 'C:\\WIN
> DOWS\\system32', 'C:\\WINDOWS',
'C:\\WINDOWS\\System32\\Wbem', 'C:\\Perl\\bin\\'
> ,'C:\\WINDOWS\\system32', 'C:\\WINDOWS',
'C:\\WINDOWS\\System32\\Wbem']
>
> There is no c:\osgeo4w\bin\g.parser.exe but there is a
C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\g.parser.exe.

This is a red herring. os.execvp() iterates through PATH, attempting
each directory in turn until it succeeds.

However, the fact that the GRASS bin and lib directories have forward
slashes might be a problem. Try correcting PATH from the command line
first.

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

[Glynn_Clements1]

Moskovitz, Bob wrote:

I noticed that most of the *.bat files have forward slashes. For example:

C:\OSGeo4W\apps\grass\bin\grass64.bat: set WINGISBASE=/c/OSGeo4W/apps/grass/grass-6.4.0RC4
C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\d.correlate.bat: @"%GRASS_SH%" -c '"%GISBASE%/scripts/d.correlate" %*'
C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\Init.bat: if "%GRASS_PROJSHARE%"=="" set GRASS_PROJSHARE=/c/OSGeo4W/share/proj
C:\OSGeo4W\bin\grass64.bat set WINGISBASE=%OSGEO4W_ROOT%/apps/grass/grass-6.4.0svn

The second one is correct, as that's the syntax which MSys' bash
requires. The rest of them are wrong.

I didn't realise that the problems with OSGeo4W were this bad.

I suggest that you use the standalone GRASS packages rather than
OSGeo4W. Or at least report OSGeo4W-specific problems to the OSGeo4W
list or tracker.

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

[bmoskovi]

Glynn Clements wrote:

1. Ensure that .py files are configured to be run with the Python
interpreter. You should be able to double-click on a .py file in
Explorer and have it run. This should be done by the Python installer,
but I don't know if the OSGeo4W installer does this.

If it isn't, you can use e.g.:

  assoc .py=python.file
  ftype python.file="C:\Program Files\Python25\python.exe" "%1"

[Change the pathname to wherever Python is installed.]

I just wanted to update you on my progress with this problem. I still can't get my script to work, but I believe I know the cause of the problem. As you can see below I've included an email you sent related to setting up python file association.

BTW, I did file an osgeo4w ticket: http://trac.osgeo.org/osgeo4w/ticket/95

After looking at the ftype help, it looks like I should have issued the command:
   ftype python.file="C:\Program Files\Python25\python.exe" "%1" %*

I've done that, but I still have the same problem. I created a simple test program that just prints out the scripts arguments:

  # printargs.py ############
  import sys

  for arg in sys.argv:
     print arg
  ###########################

And here is grass session that illustration the problem:

GRASS 6.4.0svn (Morgan_Hill)> assoc .py
.py=py_auto_file

GRASS 6.4.0svn (Morgan_Hill)> ftype py_auto_file
py_auto_file="C:\OSGeo4W\bin\python.exe" "%1" %*

GRASS 6.4.0svn (Morgan_Hill)> C:\Temp\printargs.py this is a test
C:\Temp\printargs.py

GRASS 6.4.0svn (Morgan_Hill)> python C:\Temp\printargs.py this is a test
C:\Temp\printargs.py
this
is
a
test

Bob Moskovitz
Research Analyst I
Seismic Hazard Evaluation Project
California Geological Survey
http://gmw.consrv.ca.gov/shmp

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed. This message contains information from the State of California, California Geological Survey, which may be privileged, confidential and exempt from disclosure under applicable law, including the Electronic Communications Privacy Act. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.

[Glynn_Clements1]

Moskovitz, Bob wrote:

> 1. Ensure that .py files are configured to be run with the Python
> interpreter. You should be able to double-click on a .py file in
> Explorer and have it run. This should be done by the Python installer,
> but I don't know if the OSGeo4W installer does this.
>
> If it isn't, you can use e.g.:
>
> assoc .py=python.file
> ftype python.file="C:\Program Files\Python25\python.exe" "%1"
>
> [Change the pathname to wherever Python is installed.]

I just wanted to update you on my progress with this problem. I still
can't get my script to work, but I believe I know the cause of the
problem. As you can see below I've included an email you sent related
to setting up python file association.

BTW, I did file an osgeo4w ticket:
http://trac.osgeo.org/osgeo4w/ticket/95

After looking at the ftype help, it looks like I should have issued the
command:
   ftype python.file="C:\Program Files\Python25\python.exe" "%1" %*

You don't need the trailing %*. You do need a corresponding "assoc"
command.

I've done that, but I still have the same problem. I created a simple
test program that just prints out the scripts arguments:

  # printargs.py ############
  import sys

  for arg in sys.argv:
     print arg
  ###########################

And here is grass session that illustration the problem:

GRASS 6.4.0svn (Morgan_Hill)> assoc .py
.py=py_auto_file

GRASS 6.4.0svn (Morgan_Hill)> ftype py_auto_file
py_auto_file="C:\OSGeo4W\bin\python.exe" "%1" %*

GRASS 6.4.0svn (Morgan_Hill)> C:\Temp\printargs.py this is a test
C:\Temp\printargs.py

GRASS 6.4.0svn (Morgan_Hill)> python C:\Temp\printargs.py this is a test
C:\Temp\printargs.py
this
is
a
test

Okay, so Python is working fine.

There have been some bugs fixed recently regarding g.parser on
Windows.

The first thing to check with a GRASS script is that "script --help"
generates the help message. If it doesn't, that indicates that either
g.parser isn't being called or it isn't being passed the script's
filename correctly.

If --help works but invoking the script with other arguments doesn't
work, that indicates that g.parser is failing to re-invoke the script.

If the script requires arguments, running the script without arguments
should bring up the GUI. Some bugs with this were fixed quite
recently, but I don't know if others remain.

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

[bmoskovi]

See comments below.

Glynn Clements wrote:

> GRASS 6.4.0svn (Morgan_Hill)> assoc .py
> .py=py_auto_file
>
> GRASS 6.4.0svn (Morgan_Hill)> ftype py_auto_file
> py_auto_file="C:\OSGeo4W\bin\python.exe" "%1" %*
>
> GRASS 6.4.0svn (Morgan_Hill)> C:\Temp\printargs.py this is a test
> C:\Temp\printargs.py
>
> GRASS 6.4.0svn (Morgan_Hill)> python C:\Temp\printargs.py
this is a test
> C:\Temp\printargs.py
> this
> is
> a
> test

Okay, so Python is working fine.

If python is working, can you explain why my first example ( C:\Temp\printargs.py this is a test ) only prints out sys.argv[0] ?
I believe that my problem has nothing to do with g.parser. I believe that the arguments to a python script are being stripped
when you rely on ftype.

There have been some bugs fixed recently regarding g.parser on
Windows.

Based on http://trac.osgeo.org/osgeo4w/wiki/pkg-grass, I see that OSGEO4W's GRASS (which is about 4 months old) probably don't
have many of these fixes. So, I would like to make a request to the GRASS Devs to make RC5 available to OSGEO4W. It's a shame
that the OSGEO4W community can't be involved in squashing the last few bugs

The first thing to check with a GRASS script is that "script --help"
generates the help message. If it doesn't, that indicates that either
g.parser isn't being called or it isn't being passed the script's
filename correctly.

If --help works but invoking the script with other arguments doesn't
work, that indicates that g.parser is failing to re-invoke the script.

    script --help No output
    c:\full\path\to\script --help No output
    python c:\full\path\to\script --help Help message

    script --ui No output
    c:\full\path\to\script --ui No output
    python c:\full\path\to\script --ui No output

    script --interface-description No output
    c:\full\path\to\script --interface-description No output
    python c:\full\path\to\script --interface-description XML output

If the script requires arguments, running the script without arguments
should bring up the GUI. Some bugs with this were fixed quite
recently, but I don't know if others remain.

Btw, most (if not all) of the compiled grass commands do not bring up the GUI when you run the program without arguments.

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

Bob Moskovitz
Research Analyst I
Seismic Hazard Evaluation Project
California Geological Survey
http://gmw.consrv.ca.gov/shmp

CONFIDENTIALITY NOTICE: This communication is intended only for the use of the individual or entity to which it is addressed. This message contains information from the State of California, California Geological Survey, which may be privileged, confidential and exempt from disclosure under applicable law, including the Electronic Communications Privacy Act. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.

[Glynn_Clements1]

Moskovitz, Bob wrote:

> Okay, so Python is working fine.

If python is working, can you explain why my first example
( C:\Temp\printargs.py this is a test ) only prints out sys.argv[0]
?

Sorry, I overlooked that one.

I believe that my problem has nothing to do with g.parser. I
believe that the arguments to a python script are being stripped
when you rely on ftype.

Okay; I think I know what's going on.

It appears that assoc and ftype set the registry keys:

  HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.py
  HKEY_LOCAL_MACHINE\SOFTWARE\Classes\python.file\Shell\Open\Command

[or py_auto_file, if that's what you use.]

The shell uses:

  HKEY_CLASSES_ROOT\.py
  HKEY_CLASSES_ROOT\Python.File\shell\open\command

which are "virtual" keys which refer to either:

  HKEY_CURRENT_USER\Software\Classes\Python.File\shell\open\command
  HKEY_CURRENT_USER\Software\Classes\.py

or the above HKLM keys, with the HKCU versions taking precedence. So
you can't use assoc/ftype to change the file associations if the HKCU
keys exist.

The confusion arose because both sets of keys were set to exactly the
same thing on my system.

FWIW, you do need the %* at the end of the command. If I remove that
from the HKCU keys, the arguments cease to be passed.

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

[Hamish]

> > Okay, so Python is working fine.

Bob wrote:

> If python is working, can you explain why my first example
> ( C:\Temp\printargs.py this is a test ) only prints out sys.argv[0]
> ?

Glynn:

Sorry, I overlooked that one.

> I believe that my problem has nothing to do with g.parser. I
> believe that the arguments to a python script are being stripped
> when you rely on ftype.

Okay; I think I know what's going on.

It appears that assoc and ftype set the registry keys:

    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.py
    HKEY_LOCAL_MACHINE\SOFTWARE\Classes\python.file\Shell\Open\Command

[or py_auto_file, if that's what you use.]

The shell uses:

    HKEY_CLASSES_ROOT\.py
    HKEY_CLASSES_ROOT\Python.File\shell\open\command

which are "virtual" keys which refer to either:

    HKEY_CURRENT_USER\Software\Classes\Python.File\shell\open\command
    HKEY_CURRENT_USER\Software\Classes\.py

or the above HKLM keys, with the HKCU versions taking
precedence. So you can't use assoc/ftype to change the file
associations if the HKCU keys exist.

The confusion arose because both sets of keys were set to
exactly the same thing on my system.

FWIW, you do need the %* at the end of the command. If I
remove that from the HKCU keys, the arguments cease to be passed.

just to note that the osgeo4w build is >2 months out of date now,
and the version that is shipping does not include the .py association
PATHEXT (etc.) and PATH fixes to lib/init/init.bat (etc.)

so this may be fighting battles already fought.

Hamish