@uval: "Hello
I wrote a simple module, which is also supposed to be used as standalone 
program
after considering how to avoid multiple if's I came up with this idea
if __name__ == "__main__":
    if len(sys.argv) not in (3,4):
        print "usage: prog arg1 argv2 [-x]"
    # etc ...
while develeoping I had my interpeter running and reloaded module
now since I am ready, I wanted to run it from cmd windows shell
but it always prints "usage ..."
I added print len(sys.arg) and it prints 1 though I am provinding more
than 1 value
C:\pool\vhd2h\python>vhd2h.py vhd.vhd vhd.h -o
1
usage: vhd2h.py vhdlFile hFile [-o]
Someone got an idea what may be wrong?
Daniel "
    @onurb: "<quote>
Nope. But since you're running this on a very peculiar OS, I just can
guess that this very peculiar OS consider all args to be one same string...
Try this:
if __name__ == "__main__":
  for num, arg in enumerate(sys.argv):
     print "arg %d is %s" % (num, arg)
This should art least give you some hints...
BTW, isn't the DOS syntax for command line args something like :
???
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[888a:dbb7:2d49:b3f6:8605:bf4e:caed:e5a4-1] for w in p.split('.')]) for
p in '<email_address>'.split('@')])""
    @danieldittmar: "<quote>
Add
import sys
print sys.argv
at the top of the script before any other import.
Maybe one of the modules you're importing messes with sys.argv
Daniel"
    @uval: "I just tried the same code at home and it worked fine
it has to do with windows .. some settings or whatever
(python 2.4.1 installed on both)
maybe someone have experienced the same problem
and had more luck in solving the puzzle"
    @sjmachin: "<quote>
NOT SO:
C:\junk>python -i - foo /bar -zot
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys
 >>> sys.argv
['-', 'foo', '/bar', '-zot']
NO REASON TO GUESS SO:
For *any* OS: More than one CLI (command line interpreter) a.k.a. shell 
may be available. What they do with the remainder of the command line 
after the pathname of the executable (binary program or script or 
whatever) is up to them, but I have never seen any which would lump 
space-separated tokens into one arg without some quoting convention 
having to be used.
Which DOS do you mean? IBM DOS/VS? AmigaDOS? MS-DOS?
The likelihood is that the OP is not running any of these, but is 
running a recent version of Windows. The standard CLI (cmd.exe) does use 
a syntax for built-in commands where '/' is used for options where a *x 
shell would use '-'; however this is sublimely irrelevant.
Python scripts get their args on Windows just like anywhere else. C 
programs (like the excellent collection of GnuWin32 utilities) likewise 
just do main(argc, argv) {blah; blah} and carry on regardless just as 
K&R intended."
    @bdesthquelquechose: "John Machin a �crit :
<quote>
(snip)
Your cap key got stuck ?
(snip)
"may"...
BTW, I don't remember anything like a shell in MacOS 7... (please don't 
tell me about AppleScript).
I guess I have had so frustrating experiences with Windows that I assume 
that anything that goes against common sens can happen !-)
(snip)
QDOS, of course !-)
Yes. I meant the (hum) CLI interface - which is still called "the DOS" 
by a lot of Windows users I know (at least those who already used MS-DOS 
before Windows became an OS).
I like the use of "sublimely" in this context.
Ever used Python on MacOS Classic ?
Ok, now we know that the CLI syntax is not the problem - which may be 
useful for the OP, thanks John -, and that John Machin tend to be 
somewhat reactive when one says that Windows is a somewhat peculiar OS - 
which is not really a useful information,  but what..."
    @lycka: "<quote>
First of all: "Windows" is a whole family of OSes,
and not all members have any blood relations. The
NT family is probably more related to VMS than to
MS DOS.
Secondly: There is an association mechanism (I don't
have access to Windows at work, but you can find it
in some Explorer menu) where you define what the OS
does when you try to fire off a file with a certain
extension. That mechanism defines if and how the OS
passes command line arguments.
It might we work better if you run "python x.py y z"
instead of just "x.py y z".
This might give a hint...
<url>"
    @timr: "<quote>
It's an installation problem, or maybe you tried to "fix" the installation
yourself.  I will wager real money that it works if you say this:
   python vhd2h.py vhd.vhd vhd.h -o   
When you omit the "python" name, the operating system has to figure out how
to run the command.  It does that by looking the extension up in the
registry, finding the command to run.
In a CMD shell, do this:
  c:\tmp> assoc .py
  .py=Python.File
  c:\tmp> ftype Python.File
I'm guessing yours will print something like this:
  Python.File=c:\Python24\python24.exe %1
The %1 is substituted with the name of the script being run.  In this
example, however, the parameters are all discarded.  If you set this
instead:
  c:\tmp> ftype Python.File=c:\python24\python23.exe "%1" "%*"
The "%*" says "put the rest of the parameters here."
- Tim Roberts, <email_address>
  Providenza & Boekelheide, Inc."
{'source': 'USENET', 'other_information': '{"reply_count": 7, "forum_name": "comp.lang.python.20150208.mbox"}', 'file': 'data/output/usenet-comp.lang.parquet'}