python 2.7.12 on Linux behaving differently than on Windows

BartC bc at freeuk.com
Tue Dec 6 06:43:54 EST 2016


On 06/12/2016 02:21, Dennis Lee Bieber wrote:
> On Mon, 5 Dec 2016 18:50:30 +0000, BartC <bc at freeuk.com> declaimed the
> following:
>
>> It doesn't matter, and is not the concern of the shell. It should
>> restrict itself to the basic parsing that may be necessary when
>
> 	Another name for "shell" is "command line interpreter" -- emphasis on
> "interpreter"...
>
> 	They are languages in their own right, with their own rules.

I distinguish between proper languages and those that just process 
commands like those you type in to applications that use command line input:

   > kill dwarf with axe

You don't really expect input like:

   >HOW ARE YOU?
   VERY WELL THANKS!

[An actual demo of a board computer in the 1970s] to be transformed into:

   HOW ARE YOUA YOUB YOUC

> 	The Windows command prompt being one of the weakest -- it doesn't
> support arithmetic and local variables, nor (to my knowledge) looping
> constructs.

It does some of that, but very crudely. If you want scripting, then use 
a scripting language. There are plenty about. A typical Windows user who 
uses the command prompt will have no idea they are doing coding. And 
they're not. /I/ don't expect that on Unix either.

>> One would be very annoyed if, reading a CSV file, where each of N values
>> on a line correspond to a field of record, if one entry of "?LBC"
>> expanded itself to a dozen entries, screwing everything up.
>
> 	Meaningless argument... You are, here, /reading a data file/, not
> interpreting the contents as command lines.

They're both data.

> 	Read the Python documentation for argparse

I just tried it, but it was too complex for me to set it up so as to 
discover with it did with * arguments.

> 	Again, start with argparse... Any command line argument that is left
> after it has parsed the line can likely be considered a "filename".

Only at the end?

  And to
> handle the difference between Windows and UNIX you'd likely need something
> like:
>
> for aParm in remainingArguments:
> 	for aFile in glob.glob(aParm):
> 		do something with the file

Suppose any argument contains * or ?, isn't a filename, but happens to 
match some files in the current directory. AFAICS it will still screw up.

-- 
Bartc


More information about the Python-list mailing list