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).
> 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
>
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
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.pyth
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
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! Tha
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 pa
[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,
>> 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.or
Running the script you recommended, I get
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
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 extraor
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 runn
>> 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:
> 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 ru
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
Thanks, Duncan
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
--
http://mail.python.org/mailman/listinfo/python-list
[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) se
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 t
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 argume
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 c
>> 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
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 found
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
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 suppo
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 th
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
26 matches
Mail list logo
