On Apr 2, 2005 9:06 AM, Phillip J. Eby wrote:

At 08:37 AM 4/2/05 +0200, Vivian De Smedt wrote:

...

The change in the she bang will happend only if - the win32 platform is detected (os.name == "nt") - the platform is win NT son (os.environ["OS"] == "Windows_NT")

You really need to check that COMSPEC points to cmd.exe, since as someone pointed out you can actually have an NT machine using command.com as its COMSPEC, which means it won't be able to run this either.

And just to be annoying, my COMSPEC (sometimes) points to 4NT.EXE, and I can use this feature. I support the idea, but it may not be practical. To be honest, shipping the files with a .py extension (which is directly associated with Python) in the first place is probably a better answer. Paul.

I'm sorry to be so insistent but it seems to me that my second proposition wasn't well understood. My goal wasn't to find the perfect solution but just to improve the existing solution in particular for the scripts without extensions. 1) Here is a small "demonstration" of my point a demonstration that just ask to be contradict :-) Indeed when a script have no extension it have no chance to be understood by any of the version of the win32 platform so it difficult to imagine any drawback to a modification of its she-bang. Furthermore on all version of NT it provide a working alternative with the consequence that the provided patch have benefits and no drawbacks. I everybody agree with this lets talk of the other scripts we could think to modify (the one with extension) or the other sub win32 platform we could try to find a solution for. 2) The script with extension (.py, .pyw) I think that the scripts with extension are pretty well managed on the win32 platform. The only drawback of the actual solution is that the redirection of the input isn't working and for most scripts it do not seems to me a big problem. Furthermore the extension allows the system to select which version of python to run, pythonw.exe for .pyw or python.exe for .py for some of us or, python.exe for both .py and .pyw for the one that like to see the logs of the .pyw scripts. At first glance the little advantage combined with a big drawback (but this is quit subjective) let me think that we shouldn't try to modify the extension of the scripts that have already one. 3) The other sub platforms (Dos, Win95, Win98) I do have any satisfactory solution maybe the proposition of Phillip J. Eby contains idea but not having access to any of these platform I'm in a bad position to be able to propose any solutions. Maybe: - adding a .py extension o - adding a .bat extension and a variation of the she-bang we propose for the nt sub platforms are two improvements interesting improvement we could consider. The first could also apply to the nt sub platform I personally like more my original one since it let the developer the possibility to provide scripts that support redirection of the input. Again sorry to be so insistant and so long being probably so unclear in my previous posts. Vivian.

1) Comment on the Phillip J. Eby proposition: It works well on the nt platform. - script execution - arguments passing (if less that10 :-) I suppose that the win95, win98 platform do not support the %* feature) - redirection of the input - redirection of the output - return value (%errorlevel%) I slightly prefere the following version: @shift @python script.py %0 %1 %2 %3 %4 %5 %6 %7 %8 %9 because it do not change the echo flag. 2) Advantage / Drawbacks: The advantage that I'am able to see are: - cross sub platform compatibility - close to what have been done by some package manager The drawback of this solution that I can foreseen are: - the scripts can accept only 10 arguments - the scripts could not easily be relocated Because I have too take cross platform into consideration and because I don't think relocating these script is really an issue I think the solution of Phillip J. Eby is better. 3) Small side remark. If we go for a solution that output an new file or a one that wasn't expected by the developper (script -> script.bat or script -> script and script.bat) we should cross check that the developper haven't already plan to ouput script.bat. I says that because some team did choose the solution of Phillip J. Eby with variations using sometime python and sometime pythonw according to the goal of their scripts and we should let them the flexibility to do that. Again this is just a side remark because whatever solution will be choosed we should probably take care of that. Vivian.