[M.-A. Lemburg wrote]
[Lots of different techniques to trick Windows/DOS into starting a Python script]
It is becoming rather obvious that the python -x trick is not sufficient for Windows/DOS.
I didn't even know that "-x" existed or how to use it properly. It defeats my searching abilities to find documentation for it.
E.g. perhaps we need something like:
-X n : skip the first n lines in support of OS specific startup code
And then:
@echo off pathtopython -X 4 scriptfilenamehere %0 %1 ... exit # Start of Python code [program code goes here]
Sounds useful. Note that, until now, I hadn't really grokked the point of this thread :). I was just throwing in my experiences of the Windows shell. I don't use the distutils script handling stuff at all, so am not a good person to make a call on doing this. I just saw mention of effbot's "exemaker" today: http://effbot.org/zone/exemaker.htm I *think* that having something like this would solve the problem. I've done something similar to exemaker (i.e. create little stub launcher executable for Python scripts that I distribute). I've preferred using an executable launcher stub to using a batch file partially because of the .bat syntax differences between Win9x and WinNT, but also because sometimes when breaking a process started by a batch file with Ctrl+C the shell will spit out "Would you like to stop the batch file also?" -- or something along those lines. I don't know if adding something like exemaker would be feasible or even desirable: - might cause other headaches - people might not want a launcher file separate from the script file itself One benefit of a separate launcher file over a script-in-batchfile-clothing approach: we might be able to take advantage of python's "-m" option such that a Python script that can also operate as a module (e.g. timeit.py, pydoc.py) could stay in the Lib dir and the launch could be put in the bindir. Trent -- Trent Mick TrentM@ActiveState.com