Missing file association dialog pops up all the time

[wenzeslaus]

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.

[hamish]

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

[hamish]

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

• ​http://stackoverflow.com/questions/9037346/making-python-scripts-run-on-windows-without-specifying-py-extension
• ​http://stackoverflow.com/questions/4727480/how-do-i-make-my-perl-scripts-act-like-normal-programs-on-windows

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

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

[hellik]

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.

and here for the structure of the py.ini-file:

​https://bitbucket.org/vinay.sajip/pylauncher/src/tip/Doc/launcher.rst#rst-header-customization-via-ini-files

​https://bitbucket.org/pypa/pylauncher/src/7520661dbf4cd643486f4e1ff56212e168ad7167/py.ini.template?at=default

[hellik]

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?

[wenzeslaus]

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.

[wenzeslaus]

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.