Re: [Distutils] small improvement of the script functionality under win32
Here is a small summary of the remark made arround the she-bang modification of the windows platform.
1. Trent let us know that the she-bang modification works only for the win nt sons and that in general it is better to use the .bat extension instead of the .cmd one
2. I realize that we shouldn't change the extension of a script if it exist since the extention could be usefull to determine which version of python to run - pythonw for the .pyw extention - python for the .py extention
According to these remarks and in the purpose to be as conservative as possible I make this another proposition:
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") - the original script had no extension (os.path.splitext(outfile)[1] == "")
Furthermore I add the %* in the new nt she-bang to let the underlying script know about command line argument.
such that the unix she-bang:
#!python foo bar
will become:
@C:\Python24\Python.exe -x "%%~f0" foo bar %* & exit /b
I think that in these conditions the change could only improve the existing situation at least it improve for some them (Zope, Chetaah, PyCrust, IPython)
Tell me what you think about the proposed change.
Vivian.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
On Sat, Apr 02, 2005 at 08:37:33AM +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")
I suggest using the platform module:
import platform win_nt_releases = ['NT', 'XP', '2000', '2003Server'] if platform.system() == 'Windows' and platform.release() in win_nt_releases: # do it
Regards, Bastian - -- ,''`. Bastian Kleineidam : :' : GnuPG Schlüssel `. `' gpg --keyserver wwwkeys.pgp.net --recv-keys 32EC6F3E `-
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 whatever environment variable, you need to handle the case where it doesn't exist. My Win 98 machine has no 'OS' variable, for example.
On Apr 2, 2005 9:06 AM, Phillip J. Eby pje@telecommunity.com 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.
At 10:45 AM 4/2/05 +0100, Paul Moore wrote:
On Apr 2, 2005 9:06 AM, Phillip J. Eby pje@telecommunity.com 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.
Actually, with the availability of -m, it probably makes more sense to add the ability to specify "script modules", mapping from a desired command name to a module to be run as __main__. Then, you can generate a platform-specific stub to run "python -m modulename". On Windows that could be a .bat, and on Unixish systems there could be no extension. This wouldn't help existing distributions with scripts, or anything for Python <2.4, but it seems like the "right" way to fix the problem in the long term.
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.
At 10:36 PM 4/2/05 +0200, Vivian De Smedt wrote:
- 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.
These could be resolved by creating a *second* file with a .bat extension that invokes python on the file without the extension, and passed the arguments, e.g.:
@echo off shift C:\Python24\Python C:\Python24\Scripts\scriptnamehere %0 %1 %2 %3 %4 %5 %6 %7 %8 %9
This should work on DOS and Windows 98; perhaps someone else can double check that it works on NT-based systems. If so, then this is a viable approach for all win32 platforms.
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.
participants (4)
-
Bastian Kleineidam -
Paul Moore -
Phillip J. Eby -
Vivian De Smedt