<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
On 7/20/2011 11:35 PM, Mark Hammond wrote:
<blockquote cite="mid:4E27C8BA.8040000@gmail.com" type="cite">
<pre wrap="">Customized Commands:
The launcher will support the ability to define "Customized Commands" in a
Windows .ini file (ie, a file which can be parsed by the Windows function
GetPrivateProfileString). A section called '[commands]' can be created
with key names defining the virtual command and the value specifying the
actual command-line to be used for this virtual command.
For example, if an INI file has the contents:
[commands]
vpython=c:\bin\vpython.exe -foo
Then a shebang line of '#! vpython' in a script named 'doit.py' will
result in the launcher using the command-line 'c:\bin\vpython.exe -foo
doit.py'</pre>
</blockquote>
<br>
I experimented, and empirically determined, that a customized
command can be of the form<br>
<br>
[commands]<br>
/usr/bin/perl=C:\perl\bin\perl.exe<br>
<br>
and that this works to launch Unix perl scripts on Windows
(successfully, if the perl script is actually portable).<br>
<br>
This does not contradict the above description, but may be
surprising to some. I think it is a good thing.<br>
<br>
Of course, the extra handling of versions, and locating of
corresponding installed versions of things applies only to Python,
but some may find uses for launching non-Python programs. This also
would work for python programs using non-CPython implementations
that may not set the registry in the same way. However, because
virtual commands take precedence over Customized Commands, there is
no way to override even a specific virtual command to point at a
Python other than a CPython. (perhaps some serious registry hacking
could make a non-CPython masquerade in the registry as a version of
CPython.)<br>
</body>
</html>