On 7/20/2011 11:35 PM, Mark Hammond wrote: > 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' I experimented, and empirically determined, that a customized command can be of the form [commands] /usr/bin/perl=C:\perl\bin\perl.exe and that this works to launch Unix perl scripts on Windows (successfully, if the perl script is actually portable). This does not contradict the above description, but may be surprising to some. I think it is a good thing. 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110721/b40ed116/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4