Win32: Running python programs from a Cygwin shell
JoeSmith
JoeSmith at IDontWantSpam.bogus.bogusaddress.com
Sun Feb 15 15:53:39 EST 2004
You could probably write a replacement for env that uses cygpath -m on the
script file. So, your env could call original env then do cygpath -m on the
second paramter. The one thing to think about is what the shell might do to
other file/directory paramters passed to your script. So, does it convert
foo.py .
into:
python /cygdrive/h/bin/foo.py python /cygdrive/h/bin/
Then your python script might not work. So, do you run cygpath on all paramters?
The other option would be to write a special alias/script just for foo.py to
handle on the oddities. This is what I did to get it to execute gvim for
win32. I wrote a shell function to go through all paramters and run cygpath -m
on everything that does not begin with a '-'.
If cygwin normalized everything to the cygpath -m, then I think that the
integration with win32 would be substantially better. So, in the above
scenario, you would have gotten:
python h:/bin/foo.py python h:/bin/
Both cygwin and win32 can handle this. There would be problems when passing to
CMD.exe because it would see the "/"'s and barf. I seem to remember that
therewas some setting to get command.com or cmd.exe to change the switch char.
Jorgen Grahn wrote:
> I couldn't think of a good solution, and it's hard to Google for...
>
> I write python command-line programs under Win2k, and I use the bash shell
> from Cygwin. I cannot use Cygwin's python package because of a binary
> module which has to be compiled with Visual C 6.
>
> My scripts start with a '#!/usr/bin/env python' shebang, as God intended.
>
> Now, I assume I can make cmd.exe run foo.py by asociating *.py with the
> python interpreter.
>
> However, if foo.py is in my path and I try to run it from bash, what happens
> is:
>
> - bash runs env /cygdrive/h/bin/foo.py
> - env runs something like 'python /cygdrive/h/bin/foo.py'
> - ... and python (which doesn't know about Cygwin-style paths)
> croaks on this, of course
>
> Is there a way around this, which doesn't make my script unusable if I moved
> it to a Unix box, or ran it from cmd.exe?
>
> I'd prefer not to write wrapper scripts in perl/bash/BAT...
>
> /Jorgen
>
More information about the Python-list
mailing list