Command Line arguments

[michael]

I have a question about Windows based python (2.4 and later).

For example, if I make a script called test.py like so:

import sys
print sys.argv

then run it:

python test.py this is a test

I see a list with

['test.py', 'this', 'is', 'a', 'test']


All is good!

BUT...

If i make .py extensions be run as exes (by setting the .py extension to
be executable with PATHEXT setting in environment variables, the Python
program will run, but NO arguments are passed!

For example, after setting .py extension to be executable, i get this:

test this is a test

I get ['test.py]. NO arguments are passed.

NOTE: This can NOT be blamed on Windows in my mind because Python2.2 and
earlier works FINE.

Any one have an idea?

Thank you!

Michael

 

[Tim Roberts]

I have a question about Windows based python (2.4 and later).

For example, if I make a script called test.py like so:

import sys
print sys.argv

then run it:

python test.py this is a test

I see a list with

['test.py', 'this', 'is', 'a', 'test']


All is good!

BUT...

If i make .py extensions be run as exes (by setting the .py extension to
be executable with PATHEXT setting in environment variables, the Python
program will run, but NO arguments are passed!

For example, after setting .py extension to be executable, i get this:

test this is a test

I get ['test.py]. NO arguments are passed.

NOTE: This can NOT be blamed on Windows in my mind because Python2.2 and
earlier works FINE.

It is a configuration problem. Bring up a Command Shell and run the assoc
and ftype commands like this:

C:\Tmp>assoc .py
.py=Python.File

C:\Tmp>ftype Python.File
Python.File="C:\Apps\Python24\python.exe" "%1" %*

C:\Tmp>

The KEY part of that is the %* at the end of the Python.File defintion.
That tells the system to insert the rest of the command line parameters at
that point. If you have ONLY the "%1", the command will run but no
parameters will be forwarded. If so, you can fix this by typing:

C:\Tmp>ftype Python.File="C:\Apps\Python24\python.exe" "%1" %*

Substituting your own path, of course.

 

[michael]

I have a question about Windows based python (2.4 and later).

For example, if I make a script called test.py like so:

import sys
print sys.argv

then run it:

python test.py this is a test

I see a list with

['test.py', 'this', 'is', 'a', 'test']


All is good!

BUT...

If i make .py extensions be run as exes (by setting the .py extension to
be executable with PATHEXT setting in environment variables, the Python
program will run, but NO arguments are passed!

For example, after setting .py extension to be executable, i get this:

test this is a test

I get ['test.py]. NO arguments are passed.

NOTE: This can NOT be blamed on Windows in my mind because Python2.2 and
earlier works FINE.

It is a configuration problem. Bring up a Command Shell and run the assoc
and ftype commands like this:

C:\Tmp>assoc .py
.py=Python.File

C:\Tmp>ftype Python.File
Python.File="C:\Apps\Python24\python.exe" "%1" %*

C:\Tmp>

The KEY part of that is the %* at the end of the Python.File defintion.
That tells the system to insert the rest of the command line parameters at
that point. If you have ONLY the "%1", the command will run but no
parameters will be forwarded. If so, you can fix this by typing:

C:\Tmp>ftype Python.File="C:\Apps\Python24\python.exe" "%1" %*

Substituting your own path, of course.

Tim,

I can confirm you were right! Thank you very much.

This will get us through the issue. I wonder why this was needed? One way
or the other, you taught me something and I thank you.

Michael Christopher

 

[michael]

I have a question about Windows based python (2.4 and later).

For example, if I make a script called test.py like so:

import sys
print sys.argv

then run it:

python test.py this is a test

I see a list with

['test.py', 'this', 'is', 'a', 'test']


All is good!

BUT...

If i make .py extensions be run as exes (by setting the .py extension to
be executable with PATHEXT setting in environment variables, the Python
program will run, but NO arguments are passed!

For example, after setting .py extension to be executable, i get this:

test this is a test

I get ['test.py]. NO arguments are passed.

NOTE: This can NOT be blamed on Windows in my mind because Python2.2 and
earlier works FINE.

It is a configuration problem. Bring up a Command Shell and run the assoc
and ftype commands like this:

C:\Tmp>assoc .py
.py=Python.File

C:\Tmp>ftype Python.File
Python.File="C:\Apps\Python24\python.exe" "%1" %*

C:\Tmp>

The KEY part of that is the %* at the end of the Python.File defintion.
That tells the system to insert the rest of the command line parameters at
that point. If you have ONLY the "%1", the command will run but no
parameters will be forwarded. If so, you can fix this by typing:

C:\Tmp>ftype Python.File="C:\Apps\Python24\python.exe" "%1" %*

Substituting your own path, of course.

SOLVED! Thank you.

I wonder why this was needed for 2.4 and not 2.2? I don't think it was
lingering things from old installs because it happened on a persons
computer that had never had any python installed before 2.4.

Anyway, THANKS!

Michael

 

[Trent Mick]

[michael wrote]

SOLVED! Thank you.

I wonder why this was needed for 2.4 and not 2.2? I don't think it was
lingering things from old installs because it happened on a persons
computer that had never had any python installed before 2.4.

It might be due to a bug in the Python 2.4 installer not setting the
proper file associations. What installer package did you use?

Trent

 

[michael]

[michael wrote]

SOLVED! Thank you.

I wonder why this was needed for 2.4 and not 2.2? I don't think it was
lingering things from old installs because it happened on a persons
computer that had never had any python installed before 2.4.

It might be due to a bug in the Python 2.4 installer not setting the
proper file associations. What installer package did you use?

Trent

I used the python2.4.MSI from python.org site (dated 3-6-05). I think this
was the first time they went to MSI verses an exe based installer.

it says Python 2.4 (#60 November 30th, 2004) when I start it.

Michael

 

[Trent Mick]

[michael wrote]

[Trent]

It might be due to a bug in the Python 2.4 installer not setting the
proper file associations. What installer package did you use?

I used the python2.4.MSI from python.org site (dated 3-6-05). I think this
was the first time they went to MSI verses an exe based installer.

it says Python 2.4 (#60 November 30th, 2004) when I start it.

I think Martin has been doing MSIs for a little bit longer than that,
but I'm not sure.

Martin, is it possible that there is a bug in setting up the
..py/Python.File association in the python2.4.msi? Here is the start of
this thread:

http://mail.python.org/pipermail/python-list/2005-August/296007.html

What association (if any) does your Python MSI setup?

Cheers,
Trent

 

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

I think Martin has been doing MSIs for a little bit longer than that,
but I'm not sure.

I started after 2.3, but MSIs were released for the 2.4 alpha and beta
releases, as well.

Martin, is it possible that there is a bug in setting up the
.py/Python.File association in the python2.4.msi? Here is the start of
this thread:

http://mail.python.org/pipermail/python-list/2005-August/296007.html

I don't think the 2.4 MSI has such a bug. There were various issues
in the alpha releases, but they got resolved. There was a bug in
the shortcuts (IDLE would not start if TARGETDIR had a space in it),
but that is an unrelated issue. Please refer to

http://www.python.org/2.4/bugs.html

for the most frequently reported bugs in 2.4.

What association (if any) does your Python MSI setup?

"assoc .py" gives "Python.File", "ftype Python.File" gives
Python.File="C:\Python24\python.exe" "%1" %*

This is all done through registry (i.e. no advertised extensions).
Software\Classes\.py is Python.File,
Software\Classes\Python.File\shell\open\command is
"[TARGETDIR]python.exe" "%1" %*

My guess is that the MSI file was installed "Just for me",
and then a different user tries to find the associations,
which fails as they are in the other user's profile.

Alternatively, the "Register Extensions" feature in
the "Customize Python 2.4" dialog may have been
deselected.

Regards,
Martin