469,362 Members | 2,353 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,362 developers. It's quick & easy.

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

Apr 10 '06 #1
12 4298
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.

Apr 10 '06 #2
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

Apr 10 '06 #3
In article <11**********************@i40g2000cwc.googlegroups .com>,
"BartlebyScrivener" <rp*******@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.
Apr 10 '06 #4
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
Apr 10 '06 #5
Lawrence D'Oliveiro wrote:
In article <11**********************@i40g2000cwc.googlegroups .com>,
"BartlebyScrivener" <rp*******@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.


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.

Apr 10 '06 #6
>> 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

Apr 10 '06 #7

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

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

Apr 10 '06 #8
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.
Apr 10 '06 #9
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

Apr 10 '06 #10
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

Apr 10 '06 #11
In article <Xn************************@127.0.0.1>,
Duncan Booth <du**********@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?
Apr 11 '06 #12
Lawrence D'Oliveiro wrote:
In article <Xn************************@127.0.0.1>,
Duncan Booth <du**********@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?


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).
Apr 11 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by grumfish | last post: by
2 posts views Thread by Christopher Jedlicka | last post: by
2 posts views Thread by Robert | last post: by
2 posts views Thread by KFactor | last post: by
1 post views Thread by Mayhem05 | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.