python 2.7.12 on Linux behaving differently than on Windows

[Michael Torrie]

Bored to day since it's -20 and I don't want to work outside.

On 12/05/2016 12:24 PM, BartC wrote:
>> If it sees "*", it will try to open a file named "*".
> 
> And people still say that the way Windows works is crazy!
> 
>   That's a valid
>> filename in Unix, but it should be avoided.
> 
> No, it should be prohibited, if the file API and/or shell assign special 
> significance to it.

Why? What does it matter to the file system what characters are in the
filename?

> 
>> I don't understand your concern regarding Unix shell scripting syntax.
>> On Windows, are you as troubled that environment variables such as
>> %USERNAME% get expanded by cmd.exe, but not by CreateProcess?
> 
> No, because I never use %USERNAME%, and it is obviously something 
> associated with Windows' Batch language which I hardly ever use.

cmd.exe *IS* the the "Windows' Batch" language.  So if you use cmd.exe,
you use this "Batch" language all the time.

> Not like file wildcards, which I use all the time, and don't associate 
> them exclusively with a shell.
>
> 
> I also never expect any parameter that contains ? and * to be expanded 
> then and there to whatever list of files there might happen to be. Maybe 
> the files haven't been created yet, maybe the parameter has got NOTHING 
> TO DO with filenames.
> 
> (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

I can't think of any way to do that in a consistent way.  I can see it
working for the simple cases. Must have quite a bit of logic in rename
to handle all the corner cases.

Such a syntax, even with quoting, would be highly unusual to see in the
Unix world.  I think I'd rather just use a simple loop and have the
rename be explicit so I know it's working (and yes I do this all the
time) as I expect it to.

> since, if the user forgets the second parameter, and there were two .c 
> files, it would think I wanted to rename one .c file to another.)
> 
> 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?

> 
>    >station ?LBC
> 
> 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.

I would expect in this case that the "station" program would return an
error, something like:

Error! Cannot find station "ALBC"

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.  Or change my logic
to not require this ? character (if it was part of all identifiers we
can drop it safely).

> 
>> Every command-line shell that I've ever used is also a quirky
>> scripting language.
> 
> 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.