Opened 11 years ago

Closed 10 years ago

#2015 closed defect (worksforme)

Missing file association dialog pops up all the time

Reported by: wenzeslaus Owned by: grass-dev@…
Priority: normal Milestone: 7.0.0
Component: Python Version: svn-trunk
Keywords: wingrass Cc: martinl, hellik
CPU: All Platform: MSWindows 7

Description

Summary

Doing almost anything in GRASS on MS Windows causes that "Missing file association dialog" pops up. It happens when some Python module runs. System reports that "file association" for .py file is missing, although that there is no (?) reason for it. The strange thing is that after closing the dialog, everything starts normally.

Details

This was not happening few weeks ago. It is happening for both Win 7 and Win 8 and for new GRASS 7 and also for more than half-year-old snapshot, so one would say that something changed by some Windows update. (Milestone, version, and ms win set to 7, but probably applies also for others.)

It seems that system looks for the "file association" for .py files even if you run

C:\...grass...\extrabin\python.exe C:\...myfile.py

from windows command line (as some would say DOS). It also happens if you use Popen to start a subprocess.

Setting file association to C:\...grass...\extrabin\python.exe or C:\...grass...\extrabin\pythonw.exe does help - the dialog no longer pops up. However, when the association was set to notepad, running some script in GRASS opened notepad window with the .py file, so system is using the file association to start something. I haven't noticed this with association to python.exe.

I'm also not sure when GRASS is using file association (i.e. staring python script without any python.exe) and when is using python.exe to start script (which is passed as parameter). When a later case would be the only case the file association set to some /dev/null-like program would work but its of course strange.

Strangely, newer installations of GRASS 7 should have file association set by the installer according to r54625 and r54626.

How to debug a problem

I've tried to use these commands to get some info, but they were not working (change haven't appeared):

assoc .py
ftype "Something, probably Python.File"

Also

echo %PATHEXT%

may be important, since it contains .PY in GRASS session.

Change History (8)

comment:1 by hamish, 11 years ago

one high profile change in the last week or so is source:grass/trunk/mswindows/env.bat changed to have

-set GRASS_PYTHON=python
+set GRASS_PYTHON=%GISBASE%\extrabin\python.exe

to match set PYTHONHOME=%GISBASE%\Python27 a few lines later in the same file.

try undoing that by hand and seeing if it makes a difference. also, if you do echo %PATHEXT% from outside of GRASS, is .PY already associated with a system install of python? AFAIU the official python.org installer makes some registry changes to set the file assoc. (no different than resetting it from the command line later, afaiu)

?, Hamish

comment:2 by hamish, 11 years ago

Cc: grass-dev@… removed
Component: DefaultPython
Keywords: wingrass added

comment:3 by hamish, 11 years ago

A couple quoting fixes around GRASS_PYTHON in r56927-9, but that's all start-up, nothing to do with file associations AFAICT.

Tested most recent nightly build of grass7 (r56911) with those fixes applied by hand on a fresh install of XP (so no parallel installs of other python versions), seems to be working for me.

Displaying a raster map, starting the carto composer tool worked fine for me, although an error I did see was the mapswipe tool complaining when I clicked the help button about 'NoneType' object has no attribute 'Help'.

If I do echo %PATHEXT% at a regular C:\> prompt outside of grass7 I have no .PY on the list, from a grass7 command line session I do. Do you have the same?

also try:

C:\> ftype Python.File

and

C:\> ftype | grep -i python

and

C:\> assoc | grep -i py

from within the GRASS session and look for anomalies. (maybe compare with outside a grass session, but grep might not work without extrabin in the %PATH%)

see also

hmm, Raster -> r.mask

Traceback (most recent call last):
  File "C:\Program Files\GRASS GIS
7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 737, in
OnMenuCmd

cmd = self.GetMenuCmd(event)
  File "C:\Program Files\GRASS GIS
7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 722, in
GetMenuCmd

input = GUI().GetCommandInputMapParamKey(cmdlist[0])
  File "C:\Program Files\GRASS GIS
7.0.svn\etc\gui\wxpython\gui_core\forms.py", line 2310, in
GetCommandInputMapParamKey

tree =
etree.fromstring(gtask.get_interface_description(cmd))
  File "C:\Program Files\GRASS GIS
7.0.svn\etc\python\grass\script\task.py", line 461, in
get_interface_description

"\n\nDetails: %(det)s") % { 'cmd' : cmd, 'det' :
decode(cmderr) }
grass.script.core
.
ScriptError
:
Unable to fetch interface description for command 'r.mask'.
Details: C:\Program Files\GRASS GIS
7.0.svn\extrabin\python.exe: can't open file 'r.mask':
[Errno 2] No such file or directory

but now restarting GRASS and restarting it works fine, so I'm not sure, maybe that r.mask error was just a temporary glitch(?).

Hamish

in reply to:  4 comment:6 by hellik, 11 years ago

Replying to hellik:

see thread [GRASS-dev] Python handling in winGRASS7 in dev-ML:

http://lists.osgeo.org/pipermail/grass-dev/2013-July/065137.html http://lists.osgeo.org/pipermail/grass-dev/2013-July/065140.html

and

http://docs.python.org/3/using/windows.html#launcher

for some hints.

some quick tests:

(1) Download Python 3.3.2 Windows x86 MSI Installer

(2) extract Python 3.3.2 without installing it (e.g. msiexec /a C:\dl\testunzip\python-3.3.2.msi /qb TARGETDIR=C:\dl\testunzip\uz)

(3) open a windows console in C:\dl\testunzip\uz and type py --version

C:\dl\testunzip\uz>py --version
Python 2.7.2

=> it's the system wide python 2.7.2 installed by ArcGIS10.1.

or

C:\dl\testunzip\uz>py --help
Python Launcher for Windows Version 3.3.2150.1013

usage: py [ launcher-arguments ] script [ script-arguments ]

Launcher arguments:

-2     : Launch the latest Python 2.x version
-3     : Launch the latest Python 3.x version
-X.Y   : Launch the specified Python version
-X.Y-32: Launch the specified 32bit Python version

The following help text is from Python:

usage: C:\Python27\ArcGIS10.1\python.exe [option] ... [-c cmd | -m mod | file |
-] [arg] ...
Options and arguments (and corresponding environment variables):
-B     : don't write .py[co] files on import; also PYTHONDONTWRITEBYTECODE=x
[...]

(4) script example http://docs.python.org/3/using/windows.html#from-a-script

hello.py
#! python
import sys
sys.stdout.write("hello from Python %s\n" % (sys.version,))
C:\dl\testunzip\uz>py hello.py
hello from Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Int
el)]

(5) put py.ini in the same folder as the windows python launcher py.exe.

content of py.ini which points to the osgeo4w-bundled python 2.7.4

py.ini
[commands]
myprog="C:\OSGeo4W\bin\python.exe"

and change hello.py to

#! myprog
import sys
sys.stdout.write("hello from Python %s\n" % (sys.version,))
C:\dl\testunzip\uz>py hello.py
hello from Python 2.7.4 (default, Apr  6 2013, 19:54:46) [MSC v.1500 32 bit (Int
el)]

(6) change py.ini to point to the extracted (not installed) python 3.3.2

py.ini
[commands]
myprog="C:\dl\testunzip\uz\python.exe"
C:\dl\testunzip\uz>py hello.py
hello from Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600
 32 bit (Intel)]

it seems to be possible to switch the used python interpreter by using the Python Launcher for Windows concept and point to a specfic python interpreter (installed or bundled).

could this help?

comment:7 by wenzeslaus, 11 years ago

I can again confirm this issue with r58198. I got "Select application to open .py file" dialog on Win 8 on different machine then those before. I got it only once during the start. Other possibilities not tested. It does not happen on other user accounts on the same machine.

comment:8 by wenzeslaus, 10 years ago

Resolution: worksforme
Status: newclosed

Nobody reported this issue lately now (approx r62188) and we have different method of starting Python scripts (using BAT files), so I would just consider this as caused by some MS Windows update and I'm closing the ticket as worksforme.

Reopen only if you have exactly the same problem as reported, if unsure open new ticket, the discussion here anyway does not apply to the current source code.

Note: See TracTickets for help on using tickets.