Re: [Distutils] small improvement of the script functionality under win32
At 08:14 AM 4/3/05 +0200, Vivian De Smedt wrote:
Could you confirm me that the %* isn't working on win95/win98 ?
test.bat: @echo off echo %* Running 'test test' Outputs an '*', not any arguments. So no, it doesn't work.
[Phillip J. Eby wrote]
At 08:14 AM 4/3/05 +0200, Vivian De Smedt wrote:
Could you confirm me that the %* isn't working on win95/win98 ?
test.bat: @echo off echo %*
Running 'test test' Outputs an '*', not any arguments. So no, it doesn't work.
Here is what the Perl world does with there perl2bat conversion: @rem = '--*-Perl-*-- @echo off if "%OS%" == "Windows_NT" goto WinNT perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9 goto endofperl :WinNT perl -x -S %0 %* if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl if %errorlevel% == 9009 echo You do not have Perl in your PATH. if errorlevel 1 goto script_failed_so_exit_with_non_zero_val 2>nul goto endofperl @rem '; #!perl #line 15 eval 'exec C:\Perl58\bin\perl.exe -S $0 ${1+"$@"}' if $running_under_some_shell; ... Obviously we can't do the kind of script-as-a-batch-file wrapping that Perl can get away with with its @array_variable_name syntax, but there are some good ideas here: - If one *is* using a WinNT-flavour Windows then the "%*" mechanism gets used, otherwise it gracefully falls back to the explicit "%1 %2 %3 ..." for Win9x-flavours. - If on WinNT *and* the COMSPEC is cmd.exe then the %ERRORLEVEL% 9009 code is used to deal with "perl" (in our case "python") not having properly been found. Cheers, Trent -- Trent Mick TrentM@ActiveState.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Mon, Apr 04, 2005 at 11:26:21AM -0700, Trent Mick wrote:
- If one *is* using a WinNT-flavour Windows then the "%*" mechanism gets used, otherwise it gracefully falls back to the explicit "%1 %2 %3 ..." for Win9x-flavours. I wanted to note that %* expands to an unlimited number of arguments, not just ten. Only the direct access (which you have to use under Win9x systems) is limited to the first ten with the %0-9 scheme.
Regards, Bastian - -- ,''`. Bastian Kleineidam : :' : GnuPG Schlüssel `. `' gpg --keyserver wwwkeys.pgp.net --recv-keys 32EC6F3E `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCUYwneBwlBDLsbz4RAtgvAJ4/XCIl2QFb1eAioCfbxmv+asbkGgCffOuQ A7wbjl4YRrK0iFQVTV07c4U= =+FPJ -----END PGP SIGNATURE-----
At 11:26 AM 4/4/05 -0700, Trent Mick wrote:
[Phillip J. Eby wrote]
At 08:14 AM 4/3/05 +0200, Vivian De Smedt wrote:
Could you confirm me that the %* isn't working on win95/win98 ?
test.bat: @echo off echo %*
Running 'test test' Outputs an '*', not any arguments. So no, it doesn't work.
Here is what the Perl world does with there perl2bat conversion:
@rem = '--*-Perl-*-- @echo off if "%OS%" == "Windows_NT" goto WinNT perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9 goto endofperl :WinNT perl -x -S %0 %* if NOT "%COMSPEC%" == "%SystemRoot%\system32\cmd.exe" goto endofperl if %errorlevel% == 9009 echo You do not have Perl in your PATH. if errorlevel 1 goto script_failed_so_exit_with_non_zero_val 2>nul goto endofperl @rem ';
Hm. You know, with 'python -x' you could render the above as something like: @echo off rem = """ pathtopython -x scriptfilenamehere %0 %1 ... goto finished """ [program code goes here] """ :finished rem """ Unfortunately, you have to embed the actual filename because Python doesn't have an equivalent to Perl's -S. Anyway, this isn't really a workable solution; I think creating a separate .bat file is still the best way to go.
[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. Wouldn't it be a lot cleaner if we invented a new command line switch to provide whatever parsing technique is necessary in order to provide a truely clean solution with everything in one file ? 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] -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 04 2005)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
[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
On Apr 4, 2005 10:55 PM, Trent Mick
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
To be honest, I think that personal preference issues are a big problem here. I find the "Do you want to terminate the batch file" message annoying, but I have no problem with a .py extension. I have .py registered in PATHEXT and all the necessary places to make .py files "executable" - not all of the necessary things are done by the Python installer, though (for reasons which I accept) and so this isn't a universally acceptable solution either.
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.
To be honest, the -m option (once support for packages appears, which I believe is scheduled for 2.5) probably makes script files 99% unnecessary. For people who absolutely insist on a "command", a 1-liner .bat file @pathtopython -m module %1 %2 %3 %4 %5 %6 %7 %8 %9 (avoid %* for command.com compatibility) should be adequate. With distutils support, a suitable platform-specific script like this could even be generated automatically, if needed. This is mainly a social change, though - persuading package maintainers to write their code such that -m can be used. Maybe a documentation change is the best approach. Add some text to section 2.4 (Installing Scripts) of "Distributing Python Modules" to say something like: """ By their nature, script files are inherently platform dependent - certain platforms require particular file extensions, or other conventions. Since Python 2.4, the Python executable has supported a command-line option -m (reference to the docs here) which allows modules to contain an executable section (see, for example, the timeit or compileall library modules). Where possible, writing modules which support the use of -m will be more portable than distributing standalone scripts. """ Paul.
participants (5)
-
Bastian Kleineidam -
M.-A. Lemburg -
Paul Moore -
Phillip J. Eby -
Trent Mick