Problems with GRASS python code in osgeo4w

[Moskovitz, Bob]

Some javascript/style in this post has been disabled (why?)

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.

 

 

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

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:[hidden email]]
> 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 <[hidden email]>
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

Bob Moskovitz wrote:
> 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.


try putting 'c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts' in your %PATH%.
when g.parser is complete it reruns the script but only by its filename.
If the script isn't in the PATH* it fails at that point because it
can't find it. The above seems like it should be in the path.. do other
"official" scripts in that directory work?

[*] (the current dir is typically also checked in MS Windows although it
typically is not in UNIX)

see also GRASS_ADDONS_PATH enviro variable.

for grass 7 Glynn may have just changed this a couple of days ago??



Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

I see that c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts is already in the PATH and "v.report --help" gives me the command usage.  

I do notice that there is no prompting of options or gui forms when I execute any grass command without arguments.  I've noticed this behavior on several machines.

> -----Original Message-----
> From: Hamish [mailto:[hidden email]]
> Sent: Monday, June 22, 2009 10:42 AM
> To: Glynn Clements; Moskovitz, Bob
> Cc: Grass-User (E-mail)
> Subject: RE: [GRASS-user] Problems with GRASS python code in osgeo4w
>
>
>
> Bob Moskovitz wrote:
> > 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.
>
>
> try putting 'c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts' in
> your %PATH%.
> when g.parser is complete it reruns the script but only by
> its filename.
> If the script isn't in the PATH* it fails at that point because it
> can't find it. The above seems like it should be in the
> path.. do other
> "official" scripts in that directory work?
>
> [*] (the current dir is typically also checked in MS Windows
> although it
> typically is not in UNIX)
>
> see also GRASS_ADDONS_PATH enviro variable.
>
> for grass 7 Glynn may have just changed this a couple of days ago??
>
>
>
> Hamish
>
>
>
>      
>
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

Hamish wrote:

> > 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.
>
>
> try putting 'c:\osgeo4w\apps\grass\grass-6.4.0svn\scripts' in your %PATH%.
> when g.parser is complete it reruns the script but only by its filename.

g.parser uses the filename passed as argv[1]. This needs to be the
complete path to the script, so that g.parser can fopen() it and read
the #% comments; PATH won't help here.

Unix shells normally have the full pathname as $0 (the kernel sees the
#!/bin/sh line and invokes /bin/sh with the full path to the script).
On Windows, shell scripts are invoked via windows_launch.bat, which
invokes the script by its full path.

The Python parser() function attempts to construct an absolute path,
but I don't know if this is working; it doesn't look like it. The
--help option is handled without re-invoking the script; if that
doesn't work, it suggests that g.parser cannot fopen() the script.

> If the script isn't in the PATH* it fails at that point because it
> can't find it. The above seems like it should be in the path.. do other
> "official" scripts in that directory work?
>
> [*] (the current dir is typically also checked in MS Windows although it
> typically is not in UNIX)
>
> see also GRASS_ADDONS_PATH enviro variable.
>
> for grass 7 Glynn may have just changed this a couple of days ago??

I have, but it won't make any difference in this case.

FWIW, the changes involve adding a -s switch. When used, g.parser
doesn't re-invoke the script; it simply writes all of the flag and
option settings to stdout. The Python parser() interface then parses
this output.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

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:[hidden email]]
> 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 <[hidden email]>
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

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: [hidden email]
> [mailto:[hidden email]]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)
>
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

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: [hidden email]
> > [mailto:[hidden email]]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)
> >
> >
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

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:[hidden email]]
> 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 <[hidden email]>
>

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

Bob Moskovitz:
> 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?

osgeo4w actually ships with 3: (!)

C:\OSGeo4W\apps\grass\bin\grass64(.sh) and grass64.bat  (unused)
  https://trac.osgeo.org/osgeo4w/ticket/73
  https://trac.osgeo.org/osgeo4w/ticket/90

C:\OSGeo4W\etc\ini\grass.bat  (sets enviro vars like GRASS_WISH)
  https://trac.osgeo.org/osgeo4w/ticket/86

C:\OSGeo4W\bin\grass64.bat  (and grass64.bat.tmpl)
  this is what is used to actually launch grass


Glynn:
> The rest of them are wrong.
> I didn't realise that the problems with OSGeo4W were this bad.

note what he listed above are from an unused script with OSGeo4W.
(but are used in the stand-alone installer)

things seem to work, e.g. the r.out.xyz shell script works
both from the DOS prompt and the wxGui.


> I suggest that you use the standalone GRASS packages rather than
> OSGeo4W.

if nothing else, the OSGeo4W package is rather old now (6.4svn from 4 May '9)

> Or at least report OSGeo4W-specific problems to the OSGeo4W
> list or tracker.

[except for the 3x grass.bat scripts stuff] note that in general
the stand-alone installer is built out of the osgeo4w tree &
vice versa. they're almost the same thing - at least they share
a lot.

e.g. see mswindows/osgeo4w/ in the grass source code for wxNviz
and wxVdigit linking stuff.

see https://trac.osgeo.org/osgeo4w/wiki/pkg-grass#PackagerNotes
 for partial build method.


Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

Hamish wrote:
> note what he listed above are from an unused script with
> OSGeo4W. (but are used in the stand-alone installer)

(mostly anyway)

another thing to note is that the stand-alone installer generally
gives you a msys rxvt terminal + GUI while the OSGeo4W installer
generally gives you a DOS box + GUI.

IIUC the DOS box one should call etc/Init.bat and the msys one
should call etc/Init.sh


Hamish



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

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.
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Moskovitz, Bob]

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 <[hidden email]>
>

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.

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user

[hamish-2]

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



     

_______________________________________________
grass-user mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-user