python 2.7.12 on Linux behaving differently than on Windows

BartC bc at freeuk.com
Wed Dec 7 10:48:32 EST 2016


On 07/12/2016 13:58, Dennis Lee Bieber wrote:
> On Wed, 7 Dec 2016 11:54:35 +0000, BartC <bc at freeuk.com> declaimed the
> following:
>
>> With automatic expansion, then EVERY program can become dangerous. Can
>> no one else see this?
>>
>
> 	With your scheme, EVERY PROGRAM HAS TO IMPLEMENT ITS OWN GLOBBING.

Only the tiny minority that can be meaningfully invoked on an arbitrary 
number of files at the same time.

And globbing doesn't take care of all of it: a Linux program still has 
to iterate over a loop of filenames. The same as on Windows, except the 
latter will need to call a function to deliver the next filename.

> 	The result is BLOAT and INCONSISTANT BEHAVIOR.
>
> 	UNIX shell behavior is consist ant -- you learn the rules for ONE
> shell, and they apply to ALL programs started with that shell.
>
> 	You'll respond that a library should be provided for programs to do
> that... But a C library would have to be wrapped to be used in Python, Ada,

You make it sound like a big deal. Here's a program (in my language not 
Python) which prints the list of files matching a file-spec:

println dirlist(cmdparams[2])

It's invoked like this in Windows (pcc is interpreter, t is the program):

pcc t *.c

and like this in Linux:

./pcc t "*.c"

In both cases is displays a list of .c files. The Linux needs the quotes 
because otherwise it is expanded to a list of N files, of which the 
first is taken to be the filespec, so it will print only the first.

I would prefer that the program "t" can be invoked exactly the same way 
under both systems. I don't want different instructions for Linux, or 
for the user (of my language) to have to write two lots of code, as that 
is my job:

  println dirlist(cmdparams[2])        # Windows
  println tail(cmdparams)              # Linux

(Here are implementations of that dirlist() for both OSes: 
http://pastebin.com/knciRULE

Code is my dynamic language, not C. But you can see there is not much to 
it. No 3rd party libraries apart from what comes with the OS, or that is 
part of Posix.)

> what-have-you. Thereby one now has a possibly different API in each
> language for doing something that should be the same action. Or even
> multiple APIs in one language (just look at Python's library for command
> line argument parsing:

Just look at *any* of Python's thousands of libraries.

It's always seem strange that there are libraries to do any conceivable 
thing, but people here baulk at the basics (simple ways of reading stuff 
on a line, reading a single key, and now reading /the input to a 
program/, which is pretty important).

-- 
Bartc



More information about the Python-list mailing list