Re: can't pass command-line arguments
Peter Hansen wrote: 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. Rick http://dooling.com -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Lawrence D'Oliveiro wrote: In article [EMAIL PROTECTED], Duncan Booth [EMAIL PROTECTED] 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? 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). -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
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? 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 [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
In article [EMAIL PROTECTED], BartlebyScrivener [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Lawrence D'Oliveiro enlightened us with: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Lawrence D'Oliveiro wrote: In article [EMAIL PROTECTED], BartlebyScrivener [EMAIL PROTECTED] 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
That is wrong on so many levels 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
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? http://groups.google.com/group/comp.lang.python/browse_thread/thread/8ed6d03307df1a6a/60d017deadbac420#60d017deadbac420 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
BartlebyScrivener wrote: That is wrong on so many levels 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Tim,
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
--
http://mail.python.org/mailman/listinfo/python-list
RE: can't pass command-line arguments
[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. | 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Thanks, Duncan Results of my ftype command d:\pythonftype 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Tim,
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
BartlebyScrivener wrote:
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
print running,__file__ 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
BartlebyScrivener wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Peter Hansen wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Running the script you recommended, I get d:\pythonhansen.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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
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. So remove .pyc from pathext? Rick -- http://mail.python.org/mailman/listinfo/python-list
RE: can't pass command-line arguments
[BartlebyScrivener] | 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... 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
BartlebyScrivener wrote: 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. So remove .pyc from pathext? 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
BartlebyScrivener wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
It's ActiveState. I just did a fresh install on an old machine. It appends pyo;pyc;pyw;py in that order to PATHEXT Thanks again to everyone for the generous help. Rick -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
In article [EMAIL PROTECTED], Duncan Booth [EMAIL PROTECTED] 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? -- http://mail.python.org/mailman/listinfo/python-list
can't pass command-line arguments
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
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 :)
--
http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Em Dom, 2006-04-09 às 19:41 -0700, BartlebyScrivener escreveu: for path in all_files(sysargv[1], sysargv[2]): Instead of sysargv, use sys.argv. -- Felipe. -- http://mail.python.org/mailman/listinfo/python-list
Re: can't pass command-line arguments
Duh! Headsmack. 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 -- http://mail.python.org/mailman/listinfo/python-list
