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

[Bruno Desthuilliers]

John Machin a écrit :
> bruno modulix wrote:
> 
(snip)
>>
>> 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: 

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)

>> BTW, isn't the DOS syntax for command line args something like :
>>
>>> myprog /arg1 /arg2
> 
> 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...