small improvement of the script functionality under win32

Dear disutils devloppers, First I would like to thank you for the nice job you did. I like distutils it is a very nice and powerfull way to install package. I finally found a pretext to thank you. Distutils have a script functionality that copy the corresponding file into a common script folder (that could be on the path) and sligthly modify the first line of the script to reflect the path of the python executable. It is very nice but for the window platform I think it could be improved. First the extention of the script could be .cmd such that they will be accessible as commands as soon as the script folder is in the path. Second the first line adaptation could be slightly different and take advantage of the -x option of the python executable #!python foo bar could become: @C:\Python24\python.exe -x "%~f0" foo bar & exit /b instead of: #!C:\Python24\python.exe -x "%~f0" foo bar & exit /b Follows a proposition of modification of the copy_scripts function of the build_scripts.py that reflect these changes for script in self.scripts: adjust = 0 script = convert_path(script) outfile = os.path.join(self.build_dir, os.path.basename(script)) *if os.name == "nt": outfile += ".cmd"* outfiles.append(outfile) if not self.force and not newer(script, outfile): log.debug("not copying %s (up-to-date)", script) continue # Always open the file, but ignore failures in dry-run mode -- # that way, we'll get accurate feedback if we can read the # script. try: f = open(script, "r") except IOError: if not self.dry_run: raise f = None else: first_line = f.readline() if not first_line: self.warn("%s is an empty file (skipping)" % script) continue match = first_line_re.match(first_line) if match: adjust = 1 post_interp = match.group(1) or '' if adjust: log.info("copying and adjusting %s -> %s", script, self.build_dir) if not self.dry_run: outf = open(outfile, "w") * if not sysconfig.python_build: python_path = os.path.normpath(sys.executable) else: python_path = os.path.join( sysconfig.get_config_var("BINDIR"), "python" + sysconfig.get_config_var("EXE")) if os.name == "nt": outf.write('@%s -x "%%~f0" %s & exit /b\n' % (python_path, post_interp)) else: outf.write("#!%s%s\n" % (python_path, post_interp))* outf.writelines(f.readlines()) outf.close() if f: f.close() else: f.close() self.copy_file(script, outfile) Tell me what you think about this proposition and what I should do to have a chance to integrate it into your module. Vivian.

Vivian De Smedt wrote:
Sounds like a good idea. The only thing I don't understand is why you'd want to use ".cmd" instead of the more common ".bat".
Follows a proposition of modification of the copy_scripts function of the build_scripts.py that reflect these changes
Please submit this as patch on SourceForge (http://python.sf.net). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2005)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

At 09:51 AM 3/30/05 +0200, M.-A. Lemburg wrote:
This doesn't work on Windows 98 at *all*: * 98 doesn't support .cmd files * 98 doesn't have a /b option for 'exit' * 98 doesn't pay attention to the '&' * 98 doesn't have a way to get the filename being executed (as opposed to argument 0) The closest I was able to get this to working was to use a .bat, at which point the Python part runs, but then Windows tries to execute the Python script as a batch file. Maybe somebody smarter than me can come up with a way to fix that. The following is the closest I got to a working .bat: @c:\python23\python.exe -x "%0" rem = """ @goto exit """ print "hello world" # this is the script """ :exit @rem""" This still has some important flaws; first the %0 is fragile, because it has to be the actual filename, so it's not really going to work unless Python searches PATH and PATHEXT. Second, it outputs the 'rem = """' line, and I don't know any way around that. Third, you can't have a docstring or 'from __future__'. Anyway, I guess my point is that the patch should *not* be accepted unless it actually checks whether the Windows version is high enough to support these features.

[Phillip J. Eby wrote]
If that is done, the check should be on the shell being used, i.e. command.com (which is the limited one) vs. cmd.exe. Generally this can be done by looking at the COMSPEC environment variable. For example, if one goes through Microsoft's upgrade process to upgrade from a Win9x flavour to, say, Win2k, then one's COMSPEC will still (unfortunately) be command.com. Cheers, Trent -- Trent Mick TrentM@ActiveState.com

Could we say that if: os.environ["os"] == "Windows_NT" the patch improve the existing situation? Vivian.

[Vivian De Smedt wrote]
I didn't really read the patch, so I can't give an opinion, but there is no standard OS environment variable on, e.g. Win98, so that would (at the least) have to be: os.environ.get("OS") == "Windows_NT" Still, as I said, the differentiate is more proper on what shell is being used. Trent -- Trent Mick TrentM@ActiveState.com

[Bob Ippolito wrote]
I don't know. Trying... Under the cygwin bash shell there *is* a TERM=cygwin environment variable that, I suppose, could be checked. I don't use the cygwin bash shell at all (and I don't think that people should, for various reasons including http://trentm.com/blog/?p=10). You *can* run .bat files (and I presume .cmd files as well) under Cygwin bash, but you have the specify the extension: i.e. the PATHEXT stuff doesn't work. As I said: > >I didn't really read the patch, so I can't give an opinion, but there I'm now worried that I am giving bad advice. :) Cheers, Trent -- Trent Mick TrentM@ActiveState.com

Vivian De Smedt wrote:
Sounds like a good idea. The only thing I don't understand is why you'd want to use ".cmd" instead of the more common ".bat".
Follows a proposition of modification of the copy_scripts function of the build_scripts.py that reflect these changes
Please submit this as patch on SourceForge (http://python.sf.net). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2005)
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

At 09:51 AM 3/30/05 +0200, M.-A. Lemburg wrote:
This doesn't work on Windows 98 at *all*: * 98 doesn't support .cmd files * 98 doesn't have a /b option for 'exit' * 98 doesn't pay attention to the '&' * 98 doesn't have a way to get the filename being executed (as opposed to argument 0) The closest I was able to get this to working was to use a .bat, at which point the Python part runs, but then Windows tries to execute the Python script as a batch file. Maybe somebody smarter than me can come up with a way to fix that. The following is the closest I got to a working .bat: @c:\python23\python.exe -x "%0" rem = """ @goto exit """ print "hello world" # this is the script """ :exit @rem""" This still has some important flaws; first the %0 is fragile, because it has to be the actual filename, so it's not really going to work unless Python searches PATH and PATHEXT. Second, it outputs the 'rem = """' line, and I don't know any way around that. Third, you can't have a docstring or 'from __future__'. Anyway, I guess my point is that the patch should *not* be accepted unless it actually checks whether the Windows version is high enough to support these features.

[Phillip J. Eby wrote]
If that is done, the check should be on the shell being used, i.e. command.com (which is the limited one) vs. cmd.exe. Generally this can be done by looking at the COMSPEC environment variable. For example, if one goes through Microsoft's upgrade process to upgrade from a Win9x flavour to, say, Win2k, then one's COMSPEC will still (unfortunately) be command.com. Cheers, Trent -- Trent Mick TrentM@ActiveState.com

Could we say that if: os.environ["os"] == "Windows_NT" the patch improve the existing situation? Vivian.

[Vivian De Smedt wrote]
I didn't really read the patch, so I can't give an opinion, but there is no standard OS environment variable on, e.g. Win98, so that would (at the least) have to be: os.environ.get("OS") == "Windows_NT" Still, as I said, the differentiate is more proper on what shell is being used. Trent -- Trent Mick TrentM@ActiveState.com

[Bob Ippolito wrote]
I don't know. Trying... Under the cygwin bash shell there *is* a TERM=cygwin environment variable that, I suppose, could be checked. I don't use the cygwin bash shell at all (and I don't think that people should, for various reasons including http://trentm.com/blog/?p=10). You *can* run .bat files (and I presume .cmd files as well) under Cygwin bash, but you have the specify the extension: i.e. the PATHEXT stuff doesn't work. As I said: > >I didn't really read the patch, so I can't give an opinion, but there I'm now worried that I am giving bad advice. :) Cheers, Trent -- Trent Mick TrentM@ActiveState.com
participants (5)
-
Bob Ippolito
-
M.-A. Lemburg
-
Phillip J. Eby
-
Trent Mick
-
Vivian De Smedt