can't pass command-line arguments

[BartlebyScrivener]

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

 

[Felipe Almeida Lessa]

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.

 

[BartlebyScrivener]

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

 

[Lawrence D'Oliveiro]

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]

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

 

[Duncan Booth]

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.

 

[BartlebyScrivener]

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

 

[Tim Golden]

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...03307df1a6a/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

 

[Duncan Booth]

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.

 

[BartlebyScrivener]

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

 

[BartlebyScrivener]

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

 

[Lawrence D'Oliveiro]

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?

 

[Dennis Lee Bieber]

Then why are Windows system files still restricted to 8.3 names? Doesn't
that restriction derive from a core MS-DOS-based kernel?

That's a limitation, I believe, of the FAT file system... NTFS is
not, to my understanding, that limited.

That FAT file system supported long file names essentially by adding
a look-up table to translate LFN to 8.3 which then could be found in the
FAT directory.
--

 

[Duncan Booth]

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).