len(sys.argv) in (3,4)

[Daniel Schüle]

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?

 

[bruno modulix]

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?

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 :

myprog /arg1 /arg2

???

 

[Daniel Dittmar]

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

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

 

[=?ISO-8859-15?Q?Daniel_Sch=FCle?=]

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

 

[John Machin]

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?

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

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.['-', '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.

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 :

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.

 

[Bruno Desthuilliers]

John Machin a écrit :

bruno modulix wrote:
(snip)


NOT SO:

Your cap key got stuck ?

(snip)

For *any* OS: More than one CLI (command line interpreter) a.k.a. shell
may be available.

"may"...
BTW, I don't remember anything like a shell in MacOS 7... (please don't
tell me about AppleScript).

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.

I guess I have had so frustrating experiences with Windows that I assume
that anything that goes against common sens can happen !-)

(snip)

Which DOS do you mean? IBM DOS/VS? AmigaDOS? MS-DOS?

QDOS, of course !-)

The likelihood is that the OP is not running any of these, but is
running a recent version of Windows.

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

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.

I like the use of "sublimely" in this context.

Python scripts get their args on Windows just like anywhere else.

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

 

[Magnus Lycka]

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

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...
http://www.robvanderwoude.com/call.html

 

[infidel]

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

It depends on what you're coding with. If you're writing a Win32
program in C/C++ (and by extension, Visual Basic), the WinMain()
function passes all of the arguments in a single string. One of the
many stunningly boneheaded Win32 decisions, IMNSHO.

BTW, isn't the DOS syntax for command line args something like :

No, by convention only, the "switch" character for DOS programs is "/"
instead of "-" or "--". Personally, I'm of the opinion that this
switch convention, backslashes in paths, and two-byte newlines are all
intentionally designed to make things LESS compatibile with other OSes,
and MORE difficult to interoperate.

 

[infidel]

It might make more sense if you could find out exactly what that one
argument contains.

 

[Tim Roberts]

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

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