can't pass command-line arguments
BartlebyScrivener
manually insert the values for sys.argv[1] and sys.argv[2] it works
fine, but I can't pass the variables from the command line. What am I
doing wrong? On windows xp, python 2.4.3
Thank you
import os
import fnmatch
import sys
def all_files(root, patterns='*', single_level=False,
yield_folders=False):
# Expand patterns from semicolon-separated string to list
patterns = patterns.split(';')
for path, subdirs, files in os.walk(root):
if yield_folders:
files.extend(subdirs)
files.sort()
for name in files:
for pattern in patterns:
if fnmatch.fnmatch(name, pattern):
yield os.path.join(path, name)
break
if single_level:
break
for path in all_files(sysargv[1], sysargv[2]):
print path
ps - The original script is from the excellent Python Cookbook, but
obviously I'm breaking it by trying to pass arguments to it :)
Felipe Almeida Lessa
> for path in all_files(sysargv[1], sysargv[2]):
Instead of sysargv, use sys.argv.
--
Felipe.
BartlebyScrivener
Thanks. But also, I discovered something else. If I name the script
findmyfiles.py and run it from the command line while in the directory
where it is stored (on windows), I must run it as:
findmyfiles.py d:/notes notes*.*
I was used to being able to run scripts by just typing the script name,
even without the .py extension, but
findmyfiles d:/notes notes*.* does not work
Thank you, Felipe
Lawrence D'Oliveiro
"BartlebyScrivener" <rpdo...@gmail.com> wrote:
>I was used to being able to run scripts by just typing the script name,
>even without the .py extension, but
>
>findmyfiles d:/notes notes*.* does not work
The MS-DOS foundation on which Windows is built only supports a small
number of extensions for "executable" files (.COM, .EXE and .BAT), with
no provision for any extensions to these.
Sybren Stuvel
> The MS-DOS foundation on which Windows is built only supports a
> small number of extensions for "executable" files (.COM, .EXE and
> .BAT), with no provision for any extensions to these.
Common misconception: screensavers are simply executable files with a
.scr extension. That's why they are often used to carry viruses.
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Duncan Booth
That is wrong on so many levels:
Windows variants such as NT/2000/XP are not based on MS-DOS in any way.
The default set of "executable" file extensions recognised by Windows is:
.COM .EXE .BAT .CMD .VBS .VBE .JS .JSE .WSF .WSH
You can change the recognised extensions simply by setting the PATHEXT
environment variable.
BartlebyScrivener
Including the level where I observed that I'd already been running
scripts without typing the .py extension for months, it's just that on
some scripts (seems to be the ones with functions defined in them) you
can't pass arguments unless you type the .py extension.
Anyway, thanks all.
rpd
Tim Golden
BartlebyScrivener wrote:
> I'm still new at this. I can't get this to work as a script. If I just
> manually insert the values for sys.argv[1] and sys.argv[2] it works
> fine, but I can't pass the variables from the command line. What am I
> doing wrong? On windows xp, python 2.4.3
>
[... snip code ...]>
Did you see this thread a little while ago?
In summary, it suggests looking at FTYPE and ASSOC,
and in particular at the %* param to FTYPE
The business of typing the .py or not is as secondary issue,
I suspect, and as someone else pointed out is governed by
the PATHEXT env var.
TJG
Duncan Booth
There is a problem (which I think is finally fixed in XP) where you
couldn't redirect I/O when running Python scripts via PATHEXT, but that
doesn't sound like your problem.
Defining functions, or not, doesn't sound like it should affect the
arguments, except maybe if making your script longer had an effect, but I
have no problems running a long script with arguments.
What does the command "ftype Python.File" print on your system? If it is
wrong that could easily stop arguments being passed to scripts run by
entering the script name, but it ought to break them all whether or not you
type the extension explicitly.
The only other thing I can think is that you might already have a
findmyfiles.bat (or cmd/com/exe etc.) which is the one being picked up in
place of the Python script when you don't specify an extension. That could
certainly explain the behaviour.
BartlebyScrivener
I had not seen the thread you linked to. I learned something, but it
still doesn't explain whatever is happening on my machine. When I run
assoc and ftype I get exactly the results you say I need to run the
scripts properly. However, this simple script (printargs.py) seems to
work whether I type the .py extention or not.
import os
import sys
print sys.argv
print sys.argv[0]
print sys.argv[1]
print sys.argv[2]
Whereas this more complex script (cbfindfiles.py) will NOT work unless
I type the .py extension. Otherwise the arguments don't seem to pass.
import os
import fnmatch
import sys
def all_files(root, patterns='*', single_level=False,
yield_folders=False):
"""walks the directory tree starting at root and finds all files
matching patterns"""
# Expand patterns from semicolon-separated string to list
patterns = patterns.split(';')
for path, subdirs, files in os.walk(root):
if yield_folders:
files.extend(subdirs)
files.sort()
for name in files:
for pattern in patterns:
if fnmatch.fnmatch(name, pattern):
yield os.path.join(path, name)
break
if single_level:
break
if __name__ == "__main__":
for path in all_files(sys.argv[1], sys.argv[2]):
print path
It's not big deal. I don't mind typing the .py extension. It's just a
curious quirk. Thanks for your help.
Rick
Tim Golden
| I had not seen the thread you linked to. I learned something, but it
| still doesn't explain whatever is happening on my machine. When I run
| assoc and ftype I get exactly the results you say I need to run the
| scripts properly. However, this simple script (printargs.py) seems to
| work whether I type the .py extention or not.
| Whereas this more complex script (cbfindfiles.py) will NOT work unless
| I type the .py extension. Otherwise the arguments don't seem to pass.
Well, just to confirm, it works fine for me with:
python.file="C:\Python24\python.exe" "%1" %*
but if it always succeeds with the .py extension, it's not the file
association which is getting in the way. I think someone else has
suggested checking for non-python files of the same name. (Did you
have a batch file which wrapped the python script? Some people do
that to get more control over parameters).
I've just checked the thread, and you don't seem to say what
*does* happen when you run the script, so I'm not sure how
certain you are that the params *aren't* getting through.
Have you stuck a "print sys.argv" at the top of the
"if __name__ == '__main__'" section? etc. etc.
TJG
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
BartlebyScrivener
Results of my ftype command
d:\python>ftype python.file
python.file="C:\Python24\python.exe" "%1" %*
See below, the response with examples to Tim. I'm not worried about it.
Thank you all for the education.
rick
BartlebyScrivener
No conflicting bat file.
Script name cbfindfiles.py
import os
import fnmatch
import sys
def all_files(root, patterns='*', single_level=False,
yield_folders=False):
"""walks the directory tree starting at root and finds all files
matching patterns"""
# Expand patterns from semicolon-separated string to list
patterns = patterns.split(';')
for path, subdirs, files in os.walk(root):
if yield_folders:
files.extend(subdirs)
files.sort()
for name in files:
for pattern in patterns:
if fnmatch.fnmatch(name, pattern):
yield os.path.join(path, name)
break
if single_level:
break
if __name__ == "__main__":
print sys.argv
for path in all_files(sys.argv[1], sys.argv[2]):
print path
If I run
cbfindfiles.py d:/ *emacs*
from the command prompt I get:
['d:\\python\\cbfindfiles.py', 'd:/', '*emacs*']
followed by a list of matching files
If I run
cbfindfiles d:/ *emacs*
If get an empty command prompt back.
Oh, well.
Not worth troubling over.
Thank you again.
Rick
Peter Hansen
> No conflicting bat file.
What about a conflicting non-BAT file? Anything in PATHEXT ahead of the
.PY extension is a candidate...
> if __name__ == "__main__":
> print sys.argv
> for path in all_files(sys.argv[1], sys.argv[2]):
> print path
>
> If I run
>
> cbfindfiles.py d:/ *emacs*
>
> from the command prompt I get:
>
> ['d:\\python\\cbfindfiles.py', 'd:/', '*emacs*']
> followed by a list of matching files
>
> If I run
>
> cbfindfiles d:/ *emacs*
>
> If get an empty command prompt back.
Then it's very likely not running this file... what if you put a print
at the very top of that file, saying just this:
print "running",__file__
If you don't see that, I think you have pretty good confirmation that it
is *not* in fact running that file.
> Oh, well.
>
> Not worth troubling over.
But it is. To help others. Perhaps what you are encountering is a real
bug, and solving it could avoid us having to deal with the same issue in
the future (though it seems more likely it's something special to your
case, but at least then we'll have a clear answer). Please reconsider
and investigate further.
If you run the following script and pass it the name "cbfindfiles", it
will print out a list of all files in the PATH that might be executed
when you type that name, in the order of the possible extensions in
PATHEXT. While you may be sure there's no .BAT file with that name,
maybe there is another with some other extension.
import sys
import os
name = sys.argv[1]
for dir in ['.'] + os.environ['PATH'].split(';'):
path = os.path.join(dir, name)
for ext in os.environ.get('PATHEXT', '').split(';'):
fullpath = path + ext
if os.path.isfile(fullpath):
print fullpath
-Peter
BartlebyScrivener
Well, I tried to let this die because I just KNEW I was going to look
like an idiot before it was over. It's the .pyc versus the .py file.
Obviously I don't understand how that works yet. The .pyc file lags
behind the .py file? So when I run cbfindfiles.py I'm running the .py
version and when I run cbfindfiles it's running the .pyc version which
is not the same between edits.
No need to explain. I'll go read up on how that .pyc file is generated.
Sorry for the trouble.
Rick
Peter Hansen
> Well, I tried to let this die because I just KNEW I was going to look
> like an idiot before it was over. It's the .pyc versus the .py file.
> Obviously I don't understand how that works yet. The .pyc file lags
> behind the .py file? So when I run cbfindfiles.py I'm running the .py
> version and when I run cbfindfiles it's running the .pyc version which
> is not the same between edits.
I thought of that one, of course, but it can't cause exactly the trouble
you describe above. If there's a .py in the same folder as the .pyc, it
will not use the .pyc unless the timestamp encoded in it matches the one
on the .py file (which, unless you go to extraordinary lengths, will
never screw you up that way).
On the other hand, if there was a .pyc in the current directory when you
run it with "python cbfindfiles.py", but no cbfindfiles.py in the same
folder, it will run the local one and not the .py which might be
elsewhere, in your PATH. Any chance there are cbfindfiles.py* files in
other folders or have you been doing this all from the same folder?
> No need to explain. I'll go read up on how that .pyc file is generated.
Don't think you look like an idiot (yet :-) ). Not only has everyone
been caught out by this, sometimes repeatedly (ah... it happened to a
"friend" of mine a number of times), but when you combine the weirdness
of Windows PATHEXT and FTYPE and such, you can really get into awkward
situations.
I do hope you'll identify precisely what the issue was, so we can keep
it in mind (if it's a new variant), or refresh our knowledge (if it's
just the same old same old but we didn't realize it yet).
Thanks. :-)
-Peter
Duncan Booth
> I thought of that one, of course, but it can't cause exactly the trouble
> you describe above. If there's a .py in the same folder as the .pyc, it
> will not use the .pyc unless the timestamp encoded in it matches the one
> on the .py file (which, unless you go to extraordinary lengths, will
> never screw you up that way).
>
> On the other hand, if there was a .pyc in the current directory when you
> run it with "python cbfindfiles.py", but no cbfindfiles.py in the same
> folder, it will run the local one and not the .py which might be
> elsewhere, in your PATH. Any chance there are cbfindfiles.py* files in
> other folders or have you been doing this all from the same folder?
You missed the other option: if PATHEXT has .pyc in front of .py then you
get exactly the described behaviour.
Of course that leaves open the question why anyone would want to put .pyc
into PATHEXT.
BartlebyScrivener
d:\python>hansen.py cbfindfiles
.\cbfindfiles.pyc
.\cbfindfiles.py
d:\python\cbfindfiles.pyc
d:\python\cbfindfiles.py
If I use XP search, searching all drives for any file with cbfindfiles
in the name, I get just the two in d:\python.
It has something to do with importing the cbfindfiles.py file as a
module, right? Because I just did that, and now the .py and .pyc files
are synchronized, and I'm getting the same result when I run
cbfindfiles or cbfindfiles.py, whereas before I was not.
Thank you so much for your generous help.
Rick
BartlebyScrivener
>> get exactly the described behaviour.
That's it!!
Trust me, I didn't do it. It was either ActiveState, Wing, or Komodo
Dragon, or some combination thereof.
So remove .pyc from pathext?
Rick
Tim Golden
| >> You missed the other option: if PATHEXT has .pyc in front
| of .py then you
| >> get exactly the described behaviour.
|
| That's it!!
|
| Trust me, I didn't do it. It was either ActiveState, Wing, or Komodo
| Dragon, or some combination thereof.
Amazing. I had a look, and my PATHEXT has .pyc too... but *after* .py.
I was a little confused because you seemed to be running this as
a script, not importing it as a module, but it's clear from your
other post that you had imported it as a module at least once.
Just goes to show...
Peter Hansen
Doing that will prevent a leftover .pyc file in a directory earlier in
the PATH from overriding a .py file later on in the PATH. If that was
the specific problem, definitely remove it.
Duncan, the answer to "why anyone would want to put .pyc into PATHEXT"
is at least "because that's how it's almost always recommended". At
least, I have been using that myself, probably for the same reason Rick
did, and I can see lots of search results that list it that way. I'm
just glad it was he who got caught by this and found the problem, and
not me. ;-)
I think the only reason one would want .pyc in the PATHEXT is if one
ever wanted to run .pyc files that didn't have matching .py files,
without having to specify the extension. That's certainly not a common
enough usecase to justify making ".pyc;.py" the recommended or standard
thing to add to PATHEXT.
-Peter
Peter Hansen
> It has something to do with importing the cbfindfiles.py file as a
> module, right? Because I just did that, and now the .py and .pyc files
> are synchronized, and I'm getting the same result when I run
> cbfindfiles or cbfindfiles.py, whereas before I was not.
Yes! That's the only reason you have a .pyc file at all. Normally, for
little command line scripts, Python doesn't even bother saving the
compiled code in the .pyc file. It does, however, always do this when
you use "import" so, having once imported it, you'll have that
out-of-date .pyc file kicking around forever as a latent problem.
> Thank you so much for your generous help.
You're welcome, and thanks for following this through. I still have
machines around that have PATHEXT=.pyc;.py;... and will now remove .pyc
from all of them. It would probably be nice to trace this back to the
origin, find whether there was a good rationale for it being that way in
the first place, and either update a FAQ somewhere or get the problem
fixed once and for all.
I don't think the standard install messes with PATHEXT, so my bet is on
ActiveState right now. Can anyone confirm? Trent, if you're reading
this and it is from ActiveState's distribution, do you know where that
PATHEXT=.pyc;.py choice came from and whether it might have been an
ill-advised decision that should be undone?
-Peter
BartlebyScrivener
It appends pyo;pyc;pyw;py in that order to PATHEXT
Thanks again to everyone for the generous help.
Rick
Lawrence D'Oliveiro
Duncan Booth <duncan...@invalid.invalid> wrote:
>Windows variants such as NT/2000/XP are not based on MS-DOS in any way.
Then why are Windows system files still restricted to 8.3 names? Doesn't
that restriction derive from a core MS-DOS-based kernel?
Duncan Booth
Can you give an example where the filenames are restricted to 8.3 names (as
opposed to just happening to use names which fit within 8.3)?
A lot of the files and directories in the C:\Windows folder have non 8.3
names, and though many of them aren't part of the core system they are
still 'system files'. Of course .Net is where the filenames become really
gross.
There is no MSDOS kernel in any of the the systems I mentioned.
There is an MSDOS subsystem which is loaded when required to run old
applications: NT had 5 subsytems: Win32, Posix, OS/2, MSDOS virtual
machine, and WOW (16 bit windows emulation). XP dropped the OS/2 and Posix
subsystems. XP 64-bit edition also drops the MS-DOS and WOW subsystems (it
adds a WOW64 subsystem to handle 32-bit binaries).
Trent Mick
> machines around that have PATHEXT=.pyc;.py;... and will now remove .pyc
> from all of them. It would probably be nice to trace this back to the
> origin, find whether there was a good rationale for it being that way in
> the first place, and either update a FAQ somewhere or get the problem
> fixed once and for all.
>
> I don't think the standard install messes with PATHEXT, so my bet is on
> ActiveState right now. Can anyone confirm? Trent, if you're reading
> this and it is from ActiveState's distribution, do you know where that
> PATHEXT=.pyc;.py choice came from and whether it might have been an
> ill-advised decision that should be undone?
Yes, I can confirm as well. This is a bug in ActivePython. Definitely
not an intended decision. That is: having .pyc (and/or .pyo) before .py
(and/or .pyw) on PATHEXT is definitely a bug. The ActivePython MSI just
added the .pyc, .pyo, .py and .pyw extensions to PATHEXT *backwards*. My
apologies for not having caught this.
http://bugs.activestate.com/ActivePython/show_bug.cgi?id=33311
As to whether to have .pyc (ditto .pyo) on PATHEXT at all: ActivePython
has been doing so since time immemorial. I think that ActivePython
should stop doing that (as implied by Duncan) unless someone can suggest
a reason why to keep it. The only use case would be for calling a Python
script on Windows without specifying the extension *and* for which there
is ONLY a .pyc or .pyo. That seems to unlikely (or uncommon) a scenario
to justify it.
I'll get a new ActivePython for Windows out soon to take .pyo and .pyc
off of PATHEXT.
Trent
--
Trent Mick
Tre...@ActiveState.com
BartlebyScrivener
> But it is. To help others. Perhaps what you are encountering is a real
> bug, and solving it could avoid us having to deal with the same issue in
> the future (though it seems more likely it's something special to your
> case, but at least then we'll have a clear answer). Please reconsider
> and investigate further.
Peter! You were right. It WAS a bug.
See Trent's post:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/506df1e4404353f0/c927a5585baf55f3#c927a5585baf55f3
Man, this is a big day for me. I was convinced this thread was going to
end with: "You moron! Don't you realize that is a lambda class
inheritance instance generator of a Pythonic deprecation!"
Thanks for the help and the education.