python 2.7.12 on Linux behaving differently than on Windows
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
>> 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:
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) # Windows
println tail(cmdparams) # Linux
(Here are implementations of that dirlist() for both OSes:
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).
More information about the Python-list