python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 08/12/2016 03:41, Steven D'Aprano wrote:
> On Thursday 08 December 2016 12:15, BartC wrote:
>

>> 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.

> So you're happy with the fact that there are legitimate file names that your
> program simply has no way of dealing with?

Perfectly. Such names are illegal on its home OS which is Windows, and 
ill-advised elsewhere.

Plus you're missing the fact that these are /functions/, not user 
interfaces, and are entitled to use whatever scheme they like to express 
patterns of filenames. Since it has few ambitions, it just uses 
Windows-style wildcards.

> Thank you for making my point for me! If you leave the implementation of
> metacharacter expansion

This is some feature most of my users had never heard of and never cared 
for. It only appears to exist in the CLI of some shell or other that 
runs on Linux.

> Python's fnmatch lib is a good example. It has, or at least had, no support for
> escaping metacharacters. Anyone relying on Python's fnmatch and glob modules
> alone for globbing will be unable to handle legitimate file names.

That was a good choice. This stuff might be OK for interactive user 
input in a shell. It might even be OK for sticking in a script file in 
the same language as that shell

But it DOESN'T BELONG in a general purpose library, written in a 
different language, and nothing to do with the language syntax used by 
that shell. It might *opt* to include some well-known elements (such as 
? and *), but that is a choice.

If you want full shell functionality within a program, then just invoke 
that shell!

>> 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 *.*.
>
> Correct.
>
> It doesn't matter whether metacharacters are expanded by the shell or the
> program itself, there needs to be an escaping mechanism for those cases where
> you want the metacharacters to be treated literally.

How do you write a specifier for filenames that consist of any 
characters but which must be in alphabetical order? (eg. 'forty' but not 
'fifty')

My point is it's easy to come up with a requirement that can't be 
handled. (If that one can, then I'll just think of a different one!)

(Here's one solution if I desperately needed that feature: 
http://pastebin.com/wjzu9L6L. Probably a Python one-liner given an input 
list of filenames.)

>>> 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.
>
> If you can't use it to specify a file called literally "*.*", then its not
> working.

Presumably your solution requires some intervention to turn *.* into 
something that is escaped so that it will be matched literally. But 
then, the same kind of intervention can be used to instead call 
dirlist_special():

function dirlist_special(pathandfile)=
     if checkfile(pathandfile) then
         return (extractfile(pathandfile),)
     else
         return ()
     fi
end

print dirlist_special("*.*")

>>> 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.
>
> I showed you an example in another post:
>
> [steve at ando ~]$ export base="thefile"
> [steve at ando ~]$ ls -l "$base$((1000 + 234))"
> -rw-rw-r-- 1 steve steve 0 Dec  8 10:51 thefile1234
>
>
> Of course it is silly to write 1000 + 234 as a literal constant like that, but
> either or both of those could just as easily be variables.
>
> The point here is not that *you* should build a calculator into your version of
> ls.

I don't have to do anything of the sort. I'm quite happy that the shell 
does that sort of esoteric stuff which wouldn't occur to many people to 
want to do (if they even know about it), and doesn't interfere with the 
basics.

Yes, I've written applications that use a command line, even GUI ones, 
which allows variables and expressions. But that is relevant in the 
context of that application and not outside .

Take all the programs that you run on Linux, /including GUI programs/. 
In all the situations where it requires a file-name and lets you type it 
in (not just from the shell command line, but within a program or from a 
GUI entry box), does it let you do all this meta-character and 
meta-expression stuff that you're on about?

If so, please tell me how to define '$base="thefile"' from inside 
LibreOffice, and how to make use of it in the file dialog entry box.

If not, then what you're arguing about is meaningless.

> For example, a quick and simple way of backing up a file with a date stamp:
>
> steve at runes:~$ cp alloc.txt{,-`date +%Y%m%d`}
> steve at runes:~$ ls alloc.txt*
> alloc.txt  alloc.txt-20161208

Pretty good. Except I just tried that method in Firefox to save a page:

c.html{,-`date +%Y%m%d`}

and it worked - sort of. I just got a saved page called:

c.html{,-`date +%Y%m%d`}

Does this mean Firefox is broken?


-- 
Bartc