can't pass command-line arguments

Discussion in 'Python' started by BartlebyScrivener, Apr 10, 2006.

  1. 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 :)
    BartlebyScrivener, Apr 10, 2006
    #1
    1. Advertising

  2. 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.
    Felipe Almeida Lessa, Apr 10, 2006
    #2
    1. Advertising

  3. 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
    BartlebyScrivener, Apr 10, 2006
    #3
  4. In article <>,
    "BartlebyScrivener" <> 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.
    Lawrence D'Oliveiro, Apr 10, 2006
    #4
  5. 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
    Sybren Stuvel, Apr 10, 2006
    #5
  6. BartlebyScrivener

    Duncan Booth Guest

    Lawrence D'Oliveiro wrote:

    > In article <>,
    > "BartlebyScrivener" <> 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.
    Duncan Booth, Apr 10, 2006
    #6
  7. >> 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
    BartlebyScrivener, Apr 10, 2006
    #7
  8. BartlebyScrivener

    Tim Golden Guest

    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...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
    Tim Golden, Apr 10, 2006
    #8
  9. BartlebyScrivener

    Duncan Booth Guest

    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.
    Duncan Booth, Apr 10, 2006
    #9
  10. 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, Apr 10, 2006
    #10
  11. 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
    BartlebyScrivener, Apr 10, 2006
    #11
  12. In article <Xns97A165539F6Eduncanbooth@127.0.0.1>,
    Duncan Booth <> 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?
    Lawrence D'Oliveiro, Apr 11, 2006
    #12
  13. On Tue, 11 Apr 2006 17:33:08 +1200, Lawrence D'Oliveiro
    <_zealand> declaimed the following in
    comp.lang.python:


    > 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.
    --
    > ============================================================== <
    > | Wulfraed Dennis Lee Bieber KD6MOG <
    > | Bestiaria Support Staff <
    > ============================================================== <
    > Home Page: <http://www.dm.net/~wulfraed/> <
    > Overflow Page: <http://wlfraed.home.netcom.com/> <
    Dennis Lee Bieber, Apr 11, 2006
    #13
  14. BartlebyScrivener

    Duncan Booth Guest

    Lawrence D'Oliveiro wrote:

    > In article <Xns97A165539F6Eduncanbooth@127.0.0.1>,
    > Duncan Booth <> 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).
    Duncan Booth, Apr 11, 2006
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tim Golden

    RE: can't pass command-line arguments

    Tim Golden, Apr 10, 2006, in forum: Python
    Replies:
    11
    Views:
    761
    BartlebyScrivener
    Apr 13, 2006
  2. Trent Mick

    Re: can't pass command-line arguments

    Trent Mick, Apr 11, 2006, in forum: Python
    Replies:
    0
    Views:
    390
    Trent Mick
    Apr 11, 2006
  3. kmietas
    Replies:
    6
    Views:
    509
    Default User
    Apr 19, 2006
  4. kmietas
    Replies:
    2
    Views:
    629
    Phlip
    Apr 19, 2006
  5. kj
    Replies:
    2
    Views:
    1,744
Loading...

Share This Page