python 2.7.12 on Linux behaving differently than on Windows

[BartC]

On 05/12/2016 19:48, Michael Torrie wrote:
> Bored to day since it's -20 and I don't want to work outside.
>
> On 12/05/2016 12:24 PM, BartC wrote:

>> (For example, in Windows:
>>
>>     >ren *.c *.d
>>
>> Rename all .c files to .d files. None of the .d files exist (or, because
>> of the point below, some isolated .d file exists). I wouldn't be able to
>> emulate such a command under Linux, not without writing:
>>
>>    rename *.c "*.d"
>>
>> or even:
>>
>>    rename "*.c" "*.d"
>
> Wow. Does that actually work?  And work consistently?  How would it
> handle globs like this:
>
> renamae a*b??c*.c *.d

That's not really the point, which is that a parameter may use * and ? 
which, even if they are related to file names, may not refer to actual 
input files in this directory. Here, they are output files. But this is 
just one of dozens of reasons why automatic expansion of such patterns 
is not desirable.

(And yes sometimes it works, for simple cases, and sometimes it screws 
up. But it is up to the program how it defines its input and what it 
will do with it. It shouldn't be up to the shell to expand such names in 
ALL circumstances whether that is meaningful to the app or not.)

>> But that leads to another weird behaviour I've just observed: if a
>> parameter contains a filespec with wildcards, and there is at least one
>> matching file, then you get a list of those files.
>>
>> However, if there are no matching files, you get the filespec unchanged.
>
> That's true for many shells (but not zsh by default which errors out).
>
>> Now, what is a program supposed to with that? It seems it has to deal
>> with wildcards after all. But also some behaviours can become erratic.
>> This program asks for the name of a DAB radio station:
>
> Again, it doesn't really matter.  If the program was looking for
> filenames, the program will try to open the file as given ("a*.txt") and
> if it succeeds it succeeds, if it fails it fails.  The program need not
> care. Why should it?

Really, the program should just fail? It seems to me that the program is 
then obliged to deal with wildcards after all, even if just to detect 
that wildcards have been used and that is reason for the error. But my 
example was how that behaviour can stop programs working in random ways.

>> Fine, the input is ?LBC (which is an actual station name where I live).
>> But then at some point a file ALBC comes into existence; no connection.
>> Now the same line gives the input ALBC, to perplex the user!
>
> Why would a file come into existence? I thought you said it refers to a
> station identifier. No wonder you have such confused users if you're
> creating files when you should be opening a URL or something.

The file is irrelevant. It's just a bit of junk, or something that is 
used for some other, unrelated purpose.

The important thing is that creation of that file FOR ANY REASON could 
screw up a program which is asking for input that is unrelated to any files.

> I would expect in this case that the "station" program would return an
> error, something like:
>
> Error! Cannot find station "ALBC"

And that's the error! But how is the user supposed to get round it? It's 
an error due entirely to unconditional shell expansion of any parameter 
that looks like it might be a filename with wildcards.

> If station ids were supposed to start with a wildcard character, I'd
> probably have to make a note in the help file that the station
> identifiers have to be escaped or placed in quotes.

I've no idea why that station starts with "?" (it appears on the station 
list, but have never tried to listen to it). But this is just an example 
of input that might use ? or * that has nothing to do files, yet can be 
affected by the existence of some arbitrary file.

And somebody said doing it this way is more secure than how Windows does 
things!

>> It seems shell language authors have nothing better to do than adding
>> extra quirky features that sooner or later are going to bite somebody
>> on the arse. Mainly I need a shell to help launch a program and give it
>> some basic input; that's all.
>
> I think you'd quickly find that such a shell would be very non-useful.

For about five minutes, until someone produces an add-on with the 
missing features.

-- 
Bartc