python 2.7.12 on Linux behaving differently than on Windows

[Cameron Simpson]

On 06Dec2016 16:41, BartC <bc at freeuk.com> wrote:
>On 06/12/2016 15:44, Michael Torrie wrote:
>>On 12/06/2016 04:43 AM, BartC wrote:
>>Yes shell expansion has it's gotchas.  But those can all be learned,
>
>Yes, learn to avoid wildcards in command parameters at all costs. But 
>we both know that is not satisfactory.

Sigh. I'm sure this has all been thrashed out in this huge thread, but: that is 
what quoting is for (in the shell): to control whether wildcards are expanded 
or not. You, the typist, get to decide.

>And it's not much help when someone types in:
>
> program *
>
>and the program has to try and clean up the mess, if it can see it is 
>a mess.

Some invocations will be nonsense, and a program may catch those. But if that 
was actually the typist's intent, and the program says "nah!"?

>But remember:
>
>  cp *.c
>
>There might be some irate users out there if it can't detect a simple 
>user error like that.

If there are _2_ .c files present, that will indeed misbehave. But often there 
are several, and cp detects the "copy several things to one target" mode for:

  cp a.c b.c d.c target-dir

and says the final target (eg "d.c") is not a directory. A degree of safety.  
This is the circumstance where the request, as it is received, is nonsense and 
detectably so. Not perfectly robust, but you can never be perfectly robust 
against the typist making a mistaken request, globbing or not.

>>whereas it's much harder to learn and remember all the gotchas and bugs
>>of many individual applications' unique ways of dealing with globs. I'd
>>rather deal with shells.
>
>OK, I understand. Having a program launcher indiscriminately transform 
>input A into A' is /much/ better than having it done by the program, 
>even if the program doesn't want it and it is not meaningful.

It isn't indiscriminate; quoting lets the typist discriminate. Michael's point 
is that at least you're always using the _same_ command line conventions about 
what shall be expanded and what shall not, rather than a rule per app.

>The fact that you also lose format information (is it three parameters, or one 
>parameter transformed into three) is an extra bonus.

Feh. If *.c matches 3 files and I didn't quote, it is 3 parameters in my mind.  
If I wanted one parameter I'd have said '*.c' (<== quotes).
>
>This is clearly much better than any other scheme because:
>
>(1) It's Unix not Windows; everything in Unix is always better and 
>always make sense.

UNIX rules are often simpler and more consistent.

>(2) There have been 40 years of it working this way and there have 
>never been any problems. (That is, 40 years of writing programs with 
>stultified command line interfaces to make sure that is always the case. [As 
>for 'problems' such as the 'cp *.c' one, that's a feature!]

Nothing prevents you writing an extremely simple shell yourself you know. It 
needn't expand anything. _Or_ you could have it adopt the inverse convention: 
expand nothing unless asked. Eg:

  cp G:*.c

to cause "*.c" to get expanded. Of course, because the various executables 
don't feel any burden to implement globbing you may run into some impedence 
mismatch.

Cheers,
Cameron Simpson <cs at zip.com.au>