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).
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
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
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
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
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
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.
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
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
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
[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)
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
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
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
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
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
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
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
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
--
[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
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?
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
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
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?
--
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
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
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
27 matches
Mail list logo
