<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
On 7/18/2011 4:55 PM, Vinay Sajip wrote:
<blockquote cite="mid:loom.20110719T014549-927@post.gmane.org"
type="cite">
<pre wrap="">Glenn Linderman <v+python <at> g.nevcal.com> writes:
</pre>
<blockquote type="cite">
<pre wrap=""> Here is a list of py.exe references in my registry:
HCR\Python.CompiledFile
HCR\Python.File
HCR\Python.NoConFile
</pre>
</blockquote>
<pre wrap=""> [snip]
There shouldn't be so many references, so I suggest you may want to try the
following (after backing up your registry first):</pre>
</blockquote>
<br>
So, then, there must be 2 problems... one in the launcher installer,
and the other being whatever happened to my machine.<br>
<br>
Can you list the ones there should be?<br>
<br>
<blockquote cite="mid:loom.20110719T014549-927@post.gmane.org"
type="cite">
<pre wrap="">1. Uninstall all instances of the launcher.</pre>
</blockquote>
<br>
Well, there is only one. But I can certainly remove it, and see
what happens.<br>
<br>
<blockquote cite="mid:loom.20110719T014549-927@post.gmane.org"
type="cite">
<pre wrap="">2. Remove all registry keys for .py, .pyc, .pyo, .pyw, Python.File,
Python.NoConFile, and Python.CompiledFile.</pre>
</blockquote>
Yes, I can do this.<br>
<br>
<blockquote cite="mid:loom.20110719T014549-927@post.gmane.org"
type="cite">
<pre wrap="">3. Re-install the launcher (64-bit) using "msiexec /i launchsys.amd64.msi
ALLUSERS=1" (or launcher.amd64.msi if you prefer - the only difference is the
installation directory).</pre>
</blockquote>
So what I had done was just double click launchsys.msi. Why should
there be command line parameters, rather than question/answer
dialogs? This is Windows after all. What does the parameter do,
that would be different than what double click did?<br>
<blockquote cite="mid:loom.20110719T014549-927@post.gmane.org"
type="cite">
<pre wrap="">4. Check that the removed associations have appeared under HKEY_LOCAL_MACHINE,
and that they all point to the launcher installed in the previous step. These
may also appear in HKEY_CLASSES_ROOT if it is aliased to the
HKEY_LOCAL_MACHINE\Software\Classes tree.</pre>
</blockquote>
<br>
I also still don't understand why CMD reports a different command
line via its assoc/ftype commands for the Python.File than actually
gets used by CMD to launch the .py file.<br>
<br>
Found the following at <a class="moz-txt-link-freetext" href="http://zetconsultants.com/blog/?p=36:">http://zetconsultants.com/blog/?p=36:</a><br>
<blockquote type="cite">Second issue (not really an issue, however
something that makes our situation more complicated) is the fact
that HKCR is in fact registry symlink and this registry key
doesn’t really exists on system. It is merge of two different keys
– HKLM\Software\Classes and HKCU\Software\Classes. You probably
already guessed (correctly) that this is the way how you can
overwrite some settings on per-user basis – HKCU key always wins.</blockquote>
<br>
which is useful, but still doesn't explain the variant results from
ftype and launching behavior.}<br>
<br>
They further say:<br>
<blockquote type="cite">
<p>You need to create file type using FTYPE first and then
associate this TFYPE with executable using ASSOC command. Even
though this process is not very simple, you can use it. There is
one HUGE disadvantage though and I still don’t understand how is
it possible – both FTYPE and ASSOC works only on per-machine
level! Therefore you cannot configure per-user associations
using these tools!</p>
<blockquote>
<p>Currently, there is no way through the UI to change or edit
the user-specific file type associations stored in the
HKEY_CURRENT_USER\SOFTWARE\Classes registry key. If you want
to do this, you have to directly edit the registry or develop
your own UI to gain access to this information. </p>
</blockquote>
<p>Above you can see official <a
href="http://support.microsoft.com/kb/257592/en-us">Microsoft
statement</a> about this issue.</p>
</blockquote>
<br>
So maybe the problem is that ftype and assoc report the HLM values,
but CMD actually uses the HCU values. This actually would explain
what I am seeing, and this is the piece of information I didn't
understand that caused my confusion.<br>
<br>
So as long as everything is installed for "all users", then there is
no confusion! I see I have less than 3 dozen extensions installed
in HCU, and over 800 in HLM, so clearly I choose "all users" most of
the time. It would be painstaking to see if the 3 dozen were all
consistent or not, without writing a program to help.<br>
<br>
Clearly the launcher installer should offer the same choices as
Python itself for installing for one or all users, rather than
defaulting silently to one user. Better, the default should be
inherited from the Python installation... if they are all
consistent, and if permissions allow the modification of HLM
settings.<br>
<br>
<blockquote cite="mid:loom.20110719T014549-927@post.gmane.org"
type="cite">
<pre wrap="">Regards,
Vinay Sajip
</pre>
</blockquote>
<br>
So I can fix my machine, now that I understand what went wrong
(delete py.exe entries from HCU, and put them in HLM instead).<br>
<br>
Then the other problem I have, is why py.exe launched py 2.6.4
instead of py 3.2.1 when 3.2.1 is newer, and I don't have a #!
line. That is probably the defined behavior of the launcher, to
prefer 2.x if 3 isn't specified. I'll have to reread the launcher
PEP. In my environment, I would much prefer to use 3.x if 2.x isn't
specified... so hopefully when I reread the launcher PEP, I'll
discover a way to do that. (I recall one can put -3 on the command
line, so I could do that in the py.exe ftype commands, but hopefully
there is a way to tweak the py.ini to do that.)<br>
<br>
Thanks for your response, and help in creating the launcher.<br>
</body>
</html>