python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 05/12/2016 16:49, Steve D'Aprano wrote:
> On Mon, 5 Dec 2016 10:42 pm, BartC wrote:

>> So if someone types:
>>
>>    > X A B C
>>
>> You would expect X to be launched, and be given arguments A, B and C.
>
> Would I? I don't think so.
>
> Even the DOS prompt supports some level of globbing. Its been a while since
> I've used the DOS prompt in anger, but I seem to recall being able to do
> things like:
>
> dir a*
>
> to get a listing of all the files starting with "a". So *something* is
> treating the * as a special character. In Linux and Unix, that's invariably
> the shell, before the dir command even sees what you typed.
>
> In DOS, it might be the dir command itself.

Yes, it has to be, as there is probably no space to first construct an 
in-memory list of all the files.

  The disadvantage of the DOS way
> of doing this is that *every single command and application* has to
> re-implement its own globbing, very possibly inconsistently. That's a lot
> of duplicated work and re-inventing the wheel,

Which will need to be done anyway. Expansion of filespecs with wildcards 
may need to be done from inside a program.

On Windows that involves calling FindFirstFile/FindNextFile (which takes 
care of wildcards for you), and on Linux it might be opendir/readdir 
(which doesn't; you have to call fnmatch to accept/reject each file).

(I had to port such code recently across OSes for my language; on both 
systems, dirlist(filespec) returns a list of files matching the wildcard 
specification provided. No shell expansion is needed!)

> The Unix way is far more consistent: applications typically don't have to
> care about globbing, because the shell handles glob expansion, environment
> variables, etc.

It's not consistent because program P will sometimes see * and sometimes 
a list of files. On Windows P will /never/ see a list of files if the 
start point is *. Not without a lot of intervention.

And I've already posted a long list of reasons why Linux shell's 
behaviour is undesirable, as you want to literal argument, or you want 
to do something with the filespec that is different from what the shell 
will do, or you want to do it later (perhaps the files question DON'T 
EXIST until halfway through the program).

OK I'm just thinking up more reasons why I don't like Linux shell's 
behaviour.

>> You wouldn't expect any of them to be expanded to some unknown number of
>> arguments.
>
> Actually yes I would. If they could be interpreted as file names with
> globbing or environment variables, that's exactly what I would expect.

If the syntax is:

   program filespec

or:

   program filespec file

how do you tell whether the last file in an argument list is the 
optional 'file', or the last file of the expansion of 'filespec'?

> So yes, I would expect that if I said
>
> dir a*
>
> I would get a listing of all the files starting with "a", not just the
> single file called literally "a*".

So what does 'dir' do then; just print?

Since it sounds like:

   echo *.*

would do the job just as well! (If 'echo' is a program that just lists 
its input.)

> Fine. Just escape the damn thing and do whatever you like to it.

I'm not the one running the program. Perhaps you don't know how stupid 
users can be.

>> The input is a PATTERN; I want to process it, and apply it, myself.
>
> When you double-click on a .doc file,

Are we still talking about a console or terminal here? Any filenames 
displayed as part of the dialogue (result of ls or dir for example) are 
usually not clickable.

> and Windows launches Word and opens
> the file for editing, do you rant and yell that you didn't want Word to
> open the file, you wanted to process the file name yourself?

GUIs are different.

-- 
Bartc