python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 08/12/2016 00:09, Steve D'Aprano wrote:
> On Thu, 8 Dec 2016 02:48 am, BartC wrote:

>> 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])
>
> Does dirlist provide an escaping mechanism so that you can disable filename
> globbing?

No. It simply produces a list of files in a path matching a particular 
wildcard pattern using * and ?.

That's all. I know the value of keeping things straightforward instead 
of throwing in everything you can think of. The file-matching is done by 
WinAPI functions. The Linux version was done last week and I stopped 
when I proved the concept (of having a dirlist() that worked - to 
certain specs - on both OSes, 32- and 64-bit, without change).

  In another post, you claimed that in your programs, you wouldn't
> use anything as clumsy and ambiguous as globbing.

>     My program wouldn't need anything so crude. The input syntax
>     would be more carefully designed so as to not have the ambiguity.

I meant designing a CLI where *.* could be used in different parameters 
to mean different things.

Reading that post again, you presumably meant either *.* used to match 
all files (with an embedded "." in Linux, with or without in Windows; 
another difference), or *.* used to match a specific file called *.*.


> So presumably your dirlist() command can distinguish between the file called
> literally "*.*" and the file spec "*.*" that should be expanded,

No. I won't support that (not unless it's supported by Posix's 
fnmatch()). Because it's the thin end of the wedge. I can show a few 
lines of code and then you will say, Ah, but what about this...

And I first used this function in early 90s I think, I don't recall it 
ever not working.

> And of course your program is also capable of variable and arithmetic
> expansion, right?

Um, dirlist() is used within a language, of course it can do all that. 
If you mean within the file-pattern string submitted to dirlist, then I 
don't even know what that would mean.


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

[Sorry about that name; I didn't choose it!]

> I have no idea how good the Windows globbing support is, or whether it can
> be escaped.

Why such a preoccupation with 'globbing'? It's something I may use from 
time to time with DIR or COPY or something, and that's it.

I just didn't know someone could also use it with any user program and 
that program's command line would then fill with loads of unexpected 
files that can mess things up.

  (Presumably its unambiguous because * ? [ ] are not legal in
> Windows file names?)
>
> For the Linux implementation, I don't see how extractpath and extractfile
> are defined, or fnmatch,

man fnmatch


> Looks like you have a lot of wheels that need re-inventing before you come
> even close to parity with the features of the Linux shell.

These are wheels I don't *want* to re-invent! I'm not writing a shell.

I suspect we might be talking at cross-purposes though.

-- 
Bartc